Reference architecture · reviewed 2026-05-22

B2B SaaS identity stack reference architecture

The identity architecture for a B2B SaaS product serving 100-10,000 enterprise customers with their own IdPs.

Audience

B2B SaaS founder / engineering leader / Head of Platform designing the multi-tenant identity layer.

Assumptions

Product serves 100-10,000 customer organizations
Each customer has 10-10,000 end users
Customers expect to bring their own IdP (Okta / Entra / Google / Auth0)
Compliance program in flight (SOC 2 Type 2 at minimum, often FedRAMP / HIPAA aspiration)

Components

The pieces that make it up.

Customer-facing identity platform
Auth0 / Microsoft External ID / WorkOS / Stytch. The end-user authentication layer.
Tenant / organization model
Each customer = one organization. End users belong to one or more organizations.
Federation broker
Accepts SAML + OIDC from customer IdPs. WorkOS, Auth0 Organizations, FrontEgg, or custom.
Authorization engine
Cerbos / OpenFGA / OPA — per-organization authorization with role + resource semantics.
Audit log per tenant
Customer-visible audit trail of identity + authorization decisions in their tenant.
SCIM endpoint
Receives provisioning calls from customer IdPs. RFC 7643 + 7644 conformant.
Workforce IdP (your team)
Separate from the customer-facing identity. Internal team SSO.

Key decisions

The decisions that define the architecture.

Use an organizations / tenant model, not a single user pool
A user belongs to one or more organizations. Authentication is per-organization. Authorization is per-organization. This is the load-bearing decision; getting it wrong creates a multi-year refactor.
Buy the identity platform, don't build
Auth0, Microsoft External ID, WorkOS, Stytch, FrontEgg all do this well. The build cost for a homegrown CIAM that survives compliance is 18+ engineer-months.
Customer SSO via the identity platform's native federation
Auth0 Organizations + WorkOS handle the SAML/OIDC complexity. Don't build the federation layer yourself.
SCIM for customer-driven provisioning
Enterprise customers will ask for SCIM (and pay for it). RFC 7643+7644 conformant; tested against Okta + Entra + Workday IdPs at minimum.
External authorization (Cerbos / OpenFGA / OPA)
Stuffing authorization into the application code = authorization drift across services. External PDP keeps the policy in one place + auditable.

Trade-offs

What you gain. What you pay for it.

Gain
Customer-trust differentiation (real SSO, real SCIM, real audit)
Cost
CIAM platform cost scales with MAU; budget for $50K-500K/year depending on scale.
Gain
SOC 2 Type 2 + FedRAMP-feasibility achievable
Cost
Audit cadence + evidence collection becomes a continuous workstream.
Gain
B2B Organizations pattern scales to thousands of customers
Cost
Adds complexity for very small early-stage products. Don't prematurely-organize a 5-customer startup.

The mental model

A B2B SaaS identity stack has three planes: (1) end-user authentication, scoped per organization; (2) customer admin operations (per-tenant configuration, role management, SCIM); (3) your team's workforce identity, completely separate from the customer-facing system.

Common mistakes

What goes wrong:

Treating the customer organization as just a "tag" on the user record. Doesn't survive complex enterprise scenarios (cross-org users, multi-org admins).
Building federation in-house. SAML + OIDC are easy to misimplement; let the platform do it.
Skipping SCIM. The first enterprise customer with 5K users will demand it; building it post-fact is harder than designing for it.
Authorization in code instead of policy. Drift across services accumulates fast.

Design this for us?

The reference is a starting point. We design + deliver the program.

Talk to an architectMore architectures