Designing Multi-Tenant Authentication for B2B SaaS

Consumer apps have a simple identity model: one person, one account. B2B SaaS does not. A single user might belong to three different companies, hold a different role in each, and expect to switch between them without logging out. Getting this model right early matters, because the data shape you choose for tenancy is one of the hardest things to change once you have customers.

This article covers the core decisions: how to isolate tenant data, how to model the user-to-tenant relationship, and how to handle invitations, roles, and tenant switching.

What "multi-tenant" actually means

A tenant is a customer organization. Multi-tenancy means many tenants share the same application — and possibly the same database — while remaining logically isolated from one another. The defining requirement is simple to state and easy to get wrong: one tenant must never see another tenant's data.

Three isolation models

1. Separate database per tenant

Each tenant gets its own database. Strongest isolation, easiest compliance story, but operationally heavy — migrations, backups, and connection pooling multiply by the number of tenants. Usually reserved for enterprise deals with strict data-residency requirements.

2. Shared database, separate schema

One database, one schema per tenant. A middle ground, but most ORMs and migration tools aren't built to manage hundreds of schemas gracefully.

3. Shared database, shared schema (row-level)

Every table carries a tenant_id column, and every query filters on it. This is what the vast majority of SaaS products use. It scales well and keeps operations simple — but it puts the entire isolation guarantee on your query layer.

For the shared-schema model, defense in depth is essential:

• Enforce tenant_id filtering in a single data-access layer, not scattered across the codebase.
• Use database row-level security (RLS) as a backstop so a forgotten WHERE clause can't leak data.
• Never accept tenant_id from the client as the source of truth — derive it from the authenticated session.

Modeling users and tenants

The mistake that's expensive to undo is binding a user identity to a single tenant — for example, putting tenant_id directly on the users table. The moment a customer wants to invite someone who already has an account elsewhere, that model breaks.

Model identity and membership as separate concepts:

users
  id, email (globally unique), password_hash, ...

organizations          (tenants)
  id, name, ...

memberships            (the join — one row per user-in-org)
  user_id, organization_id, role, status

A user exists once globally. A membership connects that user to an organization with a specific role. One user, many memberships, many tenants. This single decision unlocks invitations, tenant switching, and per-tenant roles cleanly.

Where tenant context lives

Once a user can belong to several tenants, every request needs to know which tenant it's acting in. Common approaches:

• Subdomain — acme.yourapp.com maps to the Acme tenant. Clean URLs, good isolation, but more DNS and certificate plumbing.
• Path prefix — /orgs/acme/.... Simple, no DNS work.
• Active tenant in the session/token — the current tenant is stored in the session or encoded as a claim in the access token.

Whatever you choose, the active tenant must come from a trusted source. If you encode it in a JWT, the token is signed, so it can't be tampered with — but you still must verify on each request that the user actually has a membership in that tenant.

Roles and authorization

Roles live on the membership, not the user — the same person can be an owner of one org and a viewer in another. Start with a small, well-defined set (owner, admin, member, viewer) and grow only when real requirements demand it. For more complex products, layer permission-based checks on top of roles so you can grant fine-grained capabilities without inventing a new role every time.

Authorization checks should always answer two questions together: Is this user a member of this tenant? and Does their role in this tenant permit this action?

Invitations

Invitations are the main way tenants grow, and they have sharp edges:

• The invited email may or may not already have an account. Your flow must handle both — accept-and-sign-up versus accept-and-join.
• Invitation tokens should be single-use, expiring, and scoped to a specific organization and role.
• Verify that the email accepting the invite matches the invited email, or you create an account-takeover vector.
• Make it possible to revoke a pending invite.

Tenant switching

Because a user can belong to many tenants, the UI needs a switcher, and the backend needs to rotate the active-tenant context safely. When a user switches:

1. Confirm they hold a valid membership in the target tenant.
2. Issue a new session or access token scoped to the new tenant.
3. Invalidate any cached authorization decisions tied to the previous tenant.

Never let the active tenant be changed by simply editing a client-side value — it must be re-validated server-side every time.

SSO and enterprise identity

Larger customers will eventually ask for SAML or OIDC single sign-on, often with their own identity provider and just-in-time user provisioning. Design for this even before you build it: keep identity (the user) separate from authentication method (password, OAuth, SSO), so adding enterprise SSO later is a new login path — not a rewrite of your user model.

A summary of the decisions that are hard to reverse

• Global user identity, separate membership records. Don't tie a user to one tenant.
• A single, enforced data-access layer for tenant_id filtering, with RLS as a backstop.
• Roles on memberships, not users.
• Active tenant derived from a trusted, signed source and re-validated per request.
• Identity decoupled from authentication method so SSO is additive.

Multi-tenant auth is mostly modeling, not cryptography. Spend the time on the data model up front — it's the part you'll regret rushing.