Multi-tenant architecture
Designing identity for a multi-tenant SaaS product
How to model users, tenants and memberships, where tenant context comes from, per-tenant policy, and the identity decisions that are hard to reverse.
The short answer
In a multi-tenant product, model a person (the identity) separately from their membership in each tenant, carry the active tenant in the verified session or token rather than in request parameters, and let security policy — session lifetimes, password rules, later SSO — vary per tenant. Decide early whether one person can belong to several tenants, because that decision is expensive to reverse.
Sources last reviewed .
Users, tenants and memberships
Two models exist. In the first, a user belongs to exactly one tenant, and the same email in two tenants is two unrelated accounts. In the second, a person has one identity and many memberships, each with its own role. The first is simpler and suits products where tenants are strictly separate. The second suits collaboration products, agencies and contractors working for several customers — and requires an explicit way to choose the active tenant.
Where tenant context comes from
Derive it from the authenticated context: a claim in the token, a value bound to the session. A tenant ID in a URL or header is fine for routing, but must be checked against the authenticated membership on every request. OWASP's API Top 10 lists broken object-level authorization first because this check is so often missing.
Per-tenant policy
Different customers have different obligations. Expect to vary idle and absolute session lifetimes, password rules, MFA requirements, allowed sign-in methods and, for larger customers, an external IdP. Build policy resolution as 'tenant setting, else platform default', and make the effective policy visible to administrators.
Decisions that are hard to reverse
- Single versus multiple memberships per person.
- Whether email is unique globally or per tenant.
- Whether tenant isolation is enforced by the database or only by application code.
- Whether machine clients belong to a tenant or to the platform.
In Authreads
How this applies to Authreads
Authreads is built around these decisions: data-layer tenant isolation, per-tenant security policy, memberships with workspace selection via RFC 8693 token exchange, and machine identity — all Available.
Authreads is a multi-tenant identity platform in beta. Capability status is maintained on /roadmap as Available, In progress or Planned.
Keep reading
Multi-tenant architecture
Tenant isolation models: silo, bridge and pool compared
Multi-tenant architecture
Organization switching: letting one user belong to many tenants
Multi-tenant architecture
Per-tenant SSO: routing each customer to their own identity provider
Glossary: Multi-tenancy · Tenant isolation · Machine identity
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.