Skip to content

Implementation blueprint

B2B SaaS CIAM with organizations, roles, and enterprise SSO

For: Engineers and architects building a multi-tenant SaaS where customers are companies.

Updated 2026-07-19

Problem context

In B2B SaaS the buyer is a company and the users belong to it. Every enterprise customer eventually asks for the same things: log in with our IdP, provision and deprovision users automatically, scope roles to our tenant, and give us an audit log. If identity was built user-first, each of these becomes a painful retrofit.

The unlock is to model the Organization as a first-class object and the configuration boundary for SSO, SCIM, domains, roles, and branding. Users then belong to one or more organizations, and enterprise features attach to the Organization rather than to the app globally.

Reference architecture

End users authenticate directly or via their company IdP. The Organization is the boundary for SSO connections, SCIM, roles, and a per-tenant audit log that customers can export to their SIEM.
End users authenticate directly or via their company IdP. The Organization is the boundary for SSO connections, SCIM, roles, and a per-tenant audit log that customers can export to their SIEM.

Core flows

Enterprise SSO login (SAML / OIDC)

A verified email domain routes the user to their organization's SSO connection. The IdP asserts identity; the CIAM issues app tokens scoped to that organization.

SP-initiated SAML: domain-based routing sends the user to their org's IdP, and the signed assertion is exchanged for app tokens.
SP-initiated SAML: domain-based routing sends the user to their org's IdP, and the signed assertion is exchanged for app tokens.

SCIM provisioning

The customer's IdP pushes user create, update, and deactivate events to the CIAM via SCIM, so joiners and leavers are handled without manual admin.

SCIM keeps the CIAM directory in sync with the customer's IdP: provisioning and, critically, deprovisioning on offboarding.
SCIM keeps the CIAM directory in sync with the customer's IdP: provisioning and, critically, deprovisioning on offboarding.

Organization data model

Users belong to organizations; roles, SSO, domains, and audit all attach to the organization, not the global app.

The Organization is the configuration boundary: SSO, SCIM, domains, roles, audit, and branding are all per-Org.
The Organization is the configuration boundary: SSO, SCIM, domains, roles, audit, and branding are all per-Org.

Data objects & boundaries

Organization / tenant
The configuration boundary: owns SSO connections, SCIM, verified domains, roles, and audit settings.
User
May belong to more than one organization; identity is global, membership and roles are per-org.
Membership
The user-to-organization link that carries the user's role within that tenant.
Role / permission
Scoped to an organization; enterprise buyers expect custom roles and least privilege.
SSO connection
Per-organization SAML or OIDC configuration, routed by verified email domain.
Audit event
Tenant-scoped, exportable log of auth and admin actions.

Required standards & protocols

  • OpenID Connect (OIDC) for app authentication
  • SAML 2.0 and OIDC for enterprise SSO federation
  • SCIM 2.0 for user provisioning and deprovisioning
  • OAuth 2.1 for API authorization

Build-vs-buy decisions

DecisionBuild ifBuy if
Enterprise SSO (SAML + OIDC)You have deep IdP expertise and only a handful of connections.You need self-serve SSO across many customer IdPs, which is almost always.
SCIM provisioningRarely worth building; the spec is fiddly and per-IdP quirks are many.You want reliable joiner/leaver automation without maintaining SCIM yourself.
Organization / tenant modelYour tenancy rules are unusual and central to your product.Standard org/role/membership needs; a platform gets you there faster.
Authorization (roles, FGA)Simple RBAC that maps cleanly to your domain.You need fine-grained, relationship-based access across resources.

Weigh the whole picture with the build-vs-buy worksheet.

Anti-patterns

Bolting tenancy on later

Adding organizations after launch means rewriting authz, data access, and the user model. Model the Organization first.

Reusing workforce IAM (Okta Workforce, Entra ID)

Workforce IAM is priced and designed for employees, not for your customers' end users; it does not fit B2B SaaS economics or UX.

One SSO connection for all tenants

Enterprise customers each bring their own IdP; SSO must be per-organization and self-serve.

No tenant-scoped audit log

Security reviews stall without per-tenant, exportable audit trails; retrofitting logging is painful.

Implementation checklist

  • Model the Organization as the configuration boundary before writing auth code
  • Support users belonging to multiple organizations
  • Route SSO by verified email domain
  • Offer self-serve SAML and OIDC connection setup
  • Automate provisioning and deprovisioning via SCIM
  • Scope roles and permissions to the organization
  • Emit a tenant-scoped, exportable audit log
  • Plan a path from RBAC to fine-grained authorization

What to require of a platform

  • Native Organizations / tenants with per-org configuration
  • Self-serve enterprise SSO (SAML and OIDC)
  • SCIM 2.0 inbound provisioning
  • Custom, org-scoped roles and permissions
  • Per-tenant audit logs with export or streaming
  • Delegated tenant administration

Related guides

Head-to-head comparisons

Compliance

Industry context

Transformation patterns

FAQ

Should I build the Organization model before or after launch?
Before. SSO, SCIM, roles, and audit all attach to the Organization, so adding tenancy after launch means rewriting authorization and data access. Model it first even if you only have a few customers.
Can I reuse workforce IAM (Okta, Entra ID) for my B2B customers?
No. Workforce IAM is priced and designed for your own employees, not your customers' end users. It does not fit B2B SaaS economics or the self-serve UX enterprise buyers expect.
Reviewed 2026-07-19. Vendor-neutral analysis; see our methodology.