B2B SaaS multi-tenant identity — the primitives that matter

B2B SaaS identity is fundamentally different from B2C. The user is not the customer — the user belongs to an organization that is the customer, and the identity surface has to make that distinction first-class. The primitives that B2B needs (organizations, invitations, scoped roles, tenant-aware SSO) are not optional polish — they are the substrate the entire product depends on.

This piece covers the primitives that matter for B2B SaaS identity, drawn from the engagements we have shipped on Auth0, Microsoft External ID, PingOne, and homegrown stacks.

The organization primitive

The first decision is whether your identity platform has a real organization primitive. Some platforms (Auth0 Organizations, Microsoft External ID tenants, Stytch B2B) make organizations first-class. Some platforms (vanilla OIDC providers, simple Auth0 deployments) require you to build organization logic on top of user metadata.

The difference is operational. A real organization primitive gives you:

• Organization-scoped roles (a user is "admin" of Acme Corp, not "admin" globally)
• Organization-bound SSO connections (Acme Corp users authenticate via their corporate IdP)
• Organization invitation flows (an admin at Acme invites a colleague; the invitation persists across login attempts)
• Organization-aware tokens (the access token includes the org context for the authorization layer)

Without a real organization primitive, every B2B SaaS team rebuilds these capabilities. The rebuild is expensive and bug-prone. We recommend the organization primitive almost always.

Invitation flows

Invitations are the canonical B2B onboarding mechanism. An organization admin invites a new user by email; the invitation creates a pending user record bound to the organization; the user accepts the invitation and provisions their identity.

The patterns that fail:

• Magic link invitations that never expire. A 6-month-old invitation that gets accepted creates an attribution problem and a security risk. We default to 7-day expiration with a written re-invite policy.
• Invitations that survive the inviter's departure. If the invitee accepts after the inviter has been deprovisioned, the invitation should fail. Most platforms get this right; some homegrown implementations do not.
• Invitations that bypass SSO. If the organization has an SSO connection, accepting an invitation should route through the SSO flow rather than allowing password-based account creation. The pattern is more secure and produces cleaner audit evidence.

We engineer the invitation flow with explicit expiration, inviter-validity checks, and SSO routing on every B2B engagement.

Tenant-aware SSO

B2B customers expect to bring their own IdP. The pattern is straightforward in principle: each customer organization configures its own SSO connection (SAML or OIDC) against the customer's IdP. When a user from that organization signs in, the auth flow routes to the customer's IdP.

The implementation details where most B2B products fail:

Discovery. How does your product know which IdP to route to? The patterns:

• Email-domain matching (users with @acme.com route to Acme's IdP)
• Subdomain routing (acme.yourproduct.com routes to Acme's IdP)
• Workspace selection UI (user selects "Acme" from a list before auth)

Each has trade-offs. Email-domain matching is the most natural but breaks for users with personal-email-domain enterprise accounts. We engineer the routing decision explicitly per product.

SAML metadata management. Customer-provided SAML metadata changes. Certificates rotate; entity IDs change after IdP migrations; assertion-signing requirements differ across IdPs. We build the metadata-management surface explicitly with a written customer-support runbook.

JIT provisioning vs invitation. When a new user from a customer organization authenticates for the first time, two patterns are credible: just-in-time provisioning (create the user automatically on first auth, with default role) or invitation-only (the user must be pre-invited by an admin). JIT is faster but creates governance gaps; invitation-only is more controlled but slower. We make the decision per customer based on their security posture.

Role and permission scoping

B2B roles are organization-scoped. A user can be "admin" of Acme Corp and "viewer" of Beta Inc — different roles in different organizations under the same user identity. The data model must support this; the authorization layer must enforce it.

Most modern platforms get this right at the data model level. The implementation gotchas are in the authorization layer:

• Permission caching. If permissions are cached at the session level, role changes can take effect with lag. For B2B products where role changes drive billing and access boundaries, we engineer explicit invalidation paths.
• Cross-organization actions. Some product surfaces aggregate across organizations (analytics dashboards, billing pages). The authorization layer must apply the right scope per surface, not the user's "highest" permission.
• Service account permissions. B2B products often need service accounts that act on behalf of organizations (CI integrations, API tokens). The scoping for these has to be explicit — and per-organization.

The audit-evidence layer

B2B customers — especially in financial services, healthcare, and the enterprise mid-market — increasingly require audit-evidence about identity events. The pattern that lands:

• Every authentication event logged with: user ID, organization ID, IdP source, IP, MFA factors used
• Every authorization decision logged with: user ID, organization ID, action attempted, decision (allowed / denied), policy applied
• Per-organization audit log export (the customer can download their org's events; not anyone else's)
• SCIM-tracked lifecycle events (user provisioned, role changed, deprovisioned)

The pattern is straightforward to engineer up front and very expensive to retrofit. We make audit-evidence capture a foundation-phase deliverable on B2B SaaS engagements.

Platform-specific notes

Auth0: Auth0 Organizations is the most polished B2B primitive in the customer-identity market. Invitation flows, organization-scoped roles, and per-organization SSO connections are all first-class.

Microsoft External ID: External ID supports multi-tenant patterns but the B2B primitive is less developed than Auth0's. For B2B SaaS products that lead with the Microsoft ecosystem, External ID is workable; for greenfield B2B SaaS, Auth0 tends to be more natural.

WorkOS: Specialized B2B SaaS identity platform with strong SSO and SCIM ergonomics. Worth evaluating when product engineering owns the customer-identity surface and Auth0's pricing or feature set is not the right fit.

Stytch B2B: Newer entrant with strong invitation and organization primitives. Worth evaluating alongside Auth0 and WorkOS.

Homegrown on top of an OIDC provider: Possible but expensive. The cost is in engineering and maintaining the organization primitives, the invitation flow, and the audit-evidence layer. For products at scale we usually recommend a platform; for unique product requirements (multi-tenant data residency, customer-managed encryption keys) homegrown is sometimes the right answer.

The bottom line

B2B SaaS identity needs primitives B2C does not — organizations, invitations, scoped roles, tenant-aware SSO. The platform-or-homegrown decision is real and the cost difference between the two is substantial. We engage early on B2B identity programs to make that decision deliberately rather than discovering the cost after launch.