How Multi-Tenant Authentication Works in B2B SaaS

Authentication answers who the person is. Multi-tenancy adds a second question: which organization is this person acting for right now? A consultant who works with three of your customers has one identity and three memberships, each with its own role.

If your model can't express that, you end up creating duplicate accounts per customer, and support tickets about 'which login do I use' follow. So the design has to settle three things up front: what uniquely identifies a person, what identifies a tenant, and where the link between them (the membership and its role) is stored.

There are three common shapes, and the tradeoffs are real:

• Shared user pool with memberships. One user record per person, a membership table linking users to organizations with a role. It handles people in several organizations cleanly and keeps your login page simple. It's the default for most B2B products.
• Pool per tenant. Each customer gets its own directory, so users, passwords and settings are fully isolated. It suits a small number of large customers with strict separation requirements, but it makes cross-tenant users awkward and multiplies operational work as tenants grow.
• Hybrid. A shared pool for everyone, plus per-tenant enterprise connections (SAML or OIDC) for customers who bring their own identity provider. Users from those tenants authenticate elsewhere, but your app still maps them to the same membership model.

If you're unsure, start with the shared pool and design the membership table so a hybrid can be added later. Going the other direction, from per-tenant pools back to one pool, means merging identities, which is painful.

Once someone is signed in, the active tenant has to be known on every request and enforced at the data layer. A workable sequence:

1. Resolve the tenant at the edge from a subdomain, a path prefix, or an explicit organization switcher, then verify the signed-in user has a membership in it.
2. Put the verified organization ID and role into the session or access token claims, so downstream services don't re-derive it from client input.
3. Pass the tenant ID into a request context object, and make your data access layer require it. A query helper that can't run without a tenant ID prevents whole classes of mistakes.
4. Enforce again in the database with a tenant column on every table and, if you use Postgres, row-level policies keyed on that column.
5. Log the user ID and tenant ID on every audit event so you can answer 'who touched this customer's data' later.

The rule underneath all five steps: the tenant comes from a verified server-side source, never from a request body, header or URL parameter that the client can edit.

Enterprise customers will eventually ask to sign in with their own identity provider. The clean approach is to store an SSO connection per organization and route by email domain: when someone types name@customer.com, you look up which organization owns that domain and redirect to its connection.

Two details matter. First, after the identity provider confirms the person, your app should still look up or create the membership, because authentication and authorization stay separate. Second, decide whether a verified SSO organization can forbid password and social login for its members. Customers' security teams tend to ask for exactly that. How hosted providers handle per-organization connections is compared in Auth0 vs Clerk vs Stytch and Clerk vs Auth0 for B2B SaaS.

These show up again and again in reviews of multi-tenant apps:

• Trusting a tenant ID sent by the client, for example an organization ID in a JSON body that the server uses without checking membership.
• Using email address as the identity key. People change addresses, and the same address can legitimately belong to several organizations.
• Storing a role on the user rather than on the membership, so an admin in one customer becomes an admin in all of them.
• Caching responses by URL without the tenant in the cache key, so one customer's page is served to another.
• Running background jobs and exports without the tenant context that web requests have, which is where unscoped queries hide.

A useful test: pick any endpoint, sign in as a user of tenant A, and try to read a tenant B record by guessing its ID. Automate that as an integration test for every route that takes an ID.

Build the membership and authorization layer yourself, because it's tied to your product's data model. Consider buying the credential layer: password storage, MFA, social login, session handling, and enterprise connections. Those are security-sensitive and slow to get right.

When you evaluate providers, test with your real tenant model. Ask how organizations, roles and invitations are represented, whether a user can belong to several organizations, and how SSO connections are configured per organization. Confirm details like limits and pricing in a demo, since they change.