Hi team! 👋 I'm building a B2B platform where each tenant has a dedicated, isolated environment with its own unique domain. Within each environment, users can access multiple projects (think: separate physical environments like Production, Development, etc.)

Environment 1
├── Production      (project)
├── Development     (project)
└── Staging         (project)

Environment 2
├── Production      (project)

My requirements: 1. Users authenticate via magic link 2. Each environment should have its own authentication context 3. Server-side validation — I want Descope's backend SDK to validate the session AND verify that the user belongs to the correct environment + project. I don't want to rely on client-side JWT decoding for authorization decisions. 4. Users should only see projects they're assigned to 5. Ideally, a custom domain for auth with cookies scoped to the parent domain I'm evaluating two approaches and would love your guidance on which is recommended: Approach A: Single Descope project, Tenant = environment, Sub-tenant = project

Descope Project: "my-platform"
├── Tenant: "env1"
│   ├── Sub-tenant: "env1-prod"          → project: Production
│   ├── Sub-tenant: "env1-dev"           → project: Development
│   └── Sub-tenant: "env1-staging"       → project: Staging
├── Tenant: "env2"
│   └── Sub-tenant: "env2-prod"          → project: Production

• One project, one custom domain, shared cookies across environments • Role inheritance from parent tenant → sub-tenants • Server-side validation: middleware identifies the environment context, calls

validateSession()

, and needs to verify that the user belongs to the matching tenant — is there a way to do this entirely on Descope's server side, rather than having my middleware compare the tenant list from the session manually? Approach B: Descope project per environment, Tenant = project

Descope Project: "env1"
├── Tenant: "prod"                    → project: Production
├── Tenant: "dev"                     → project: Development
└── Tenant: "staging"                 → project: Staging

Descope Project: "env2"
├── Tenant: "prod"                    → project: Production

• Full isolation per environment at the Descope level • Each environment has its own project ID, flows, and settings • Tenant validation is scoped to the project — a user can only exist within that environment's project My specific questions: 1. Which approach do you recommend for this architecture? Are there trade-offs I'm not seeing? 2. Server-side tenant validation: Can Descope handle the enforcement of "this session is only valid for tenant X" on the server side? For example, if a user authenticated in the context of env1, I want the server-side validation to reject that session when used in the context of env2 — without my middleware having to decode the JWT and compare tenants manually. Is there a pattern or API for this? 3. Is there a way to have Descope enforce "this user can only authenticate in the context of tenant X" at the flow level, so the validation is built into the auth process itself? 4. If using Approach B (project per environment): is there a recommended pattern for managing multiple Descope projects at scale (shared flows, consistent settings, etc.)? Thanks in advance! 🙏

@Avi Glozman @Bhagyesh Parna can you follow up here?

Hi Rani! I'd go with your approach A here. If I understand your use-case correctly, you may need to do some tenant validation in your middleware, however there's backend SDK tooling for that (more details here and here), and you can also build this into your flows.