TL;DR — Multi-tenant auth lives at three layers — tenant resolution (which tenant is this user logging into), user authentication (who are they), and authorization (what can they do here). Each layer has a clear pattern; the failure mode is mixing them.
Multi-tenant auth gets messy when teams blend tenant identity, user identity and authorization. Separating them into three layers — each with its own contract — is what makes the system tractable.
Layer 1: Tenant resolution
How do we know which tenant the user is acting for? Patterns:
- Subdomain —
acme.app.com. Clean URL signal, easy to reason about, requires wildcard DNS. - Path prefix —
/t/acme/dashboard. Easier setup, uglier URLs. - Header / session — tenant ID lives in the session after login. Simplest, weakest URL semantics.
Layer 2: User authentication
Who is this user? Buy this layer:
- Auth0 / Clerk — SaaS, covers email + social + SSO
- WorkOS — B2B-focused, enterprise SSO and SCIM
- Ory / Keycloak — self-hosted if you must
This layer should be replaceable. Hide it behind a small wrapper so swapping vendors is feasible.
Layer 3: Authorization
What can this user do in this tenant? Patterns by stage:
- Role-based — admin, member, viewer. Enough for most B2B early on.
- Permission-based — discrete permissions assigned to roles. More flexible, more complex.
- Resource-scoped — permissions tied to specific resources (project X, folder Y). Needed when tenants have internal hierarchies.
The user-in-multiple-tenants question
A single human can belong to multiple tenants. The auth layer issues one identity; the tenant resolution layer decides which tenant context applies for this session. Tenant-switch UX needs care — users should see explicitly which tenant they are in.
SCIM
For enterprise customers, SCIM (System for Cross-domain Identity Management) lets their HR system provision users automatically. Implement it via your auth vendor — building it from scratch is unreasonable.
The failure modes
- Mixing tenant ID with user ID — splitting them later is painful
- Hardcoding role names in code — use a permission layer even if roles are simple
- Building auth in-house “to save money” — the bug cost dwarfs the savings
Frequently asked questions
Do I need SAML and OIDC?
For B2B SaaS sold to enterprise, yes. Enterprise customers ask for SAML. New buyers prefer OIDC. Both means you reach both buyer segments.
Should I build auth or buy it?
Buy. Auth0, Clerk, WorkOS — pick one. The differentiator your product has is not auth; the cost of getting auth wrong is reputational and legal.
Working on something similar?
T-Square architects, builds and operates production systems for learning, AI and custom software products. Talk to a senior engineer for a second opinion.