CIAM Reference Architectures: Four Patterns and the Vendors That Fit
Updated 2026-06-08 · 14 min read · By @guptadeepak
Key takeaways
- There is no single best CIAM architecture. There are four common patterns chosen by identity shape and constraints.
- B2C mobile-first optimizes for conversion, passwordless, and cost per MAU at volume.
- B2B multi-tenant lives or dies on the Organizations model, per-tenant SSO, and SCIM.
- Hybrid B2B2C needs two clean identity planes, not one tangled user pool.
- Regulated and self-hosted is decided by data residency and a compliance floor first; the real cost is operations.
How to use this guide
Match your situation to one of the four patterns, confirm the non-negotiable capabilities, and then take that capability set to the vendor index and comparisons. If you are not yet sure which pattern you are in, work through Start here first. Each pattern below names vendor types rather than a single winner, because cost behavior and constraints still decide the final choice.
Pattern 1: B2C mobile-first
High-volume consumer identity where every extra step costs conversion and cost-per-MAU dominates the bill.
Mobile / web app
|
[ CIAM ] --- social login, passkeys, magic links, email/SMS OTP
| |
sessions fraud / bot signals (device, velocity, risk)
|
profile + consent ---> marketing / CDP, analytics
Non-negotiable capabilities. Passwordless and passkeys as the primary path; social login at scale; strong registration conversion; bot and fraud signals; and a pricing model that stays sane past 100k MAU. Tenancy is flat, so the Organizations model is irrelevant.
Failure mode. Choosing a B2B-leaning platform "to be safe" and watching the per-MAU bill become the largest line item by the time you reach scale. The second failure is treating passkeys as a checkbox rather than designing the enrollment and conditional-UI flow that actually drives adoption.
Vendor type that fits. Developer-first and B2C-specialist platforms, with hyperscaler-native and open-source options once cost dominates. See the consumer-apps vertical and the passwordless guide. When cost is the binding constraint at volume, weigh the Auth0 alternatives and Firebase alternatives.
Pattern 2: B2B multi-tenant SaaS
Your customers are companies. Each is a tenant with its own users, roles, and, once you sell upmarket, its own identity provider.
[ CIAM ]
/ | \
Org A Org B Org C
| \ | |
users SAML users users
IdP OIDC IdP (password/passkey)
+ SCIM provisioning per org
+ per-org roles, policies, audit
Non-negotiable capabilities. A first-class Organizations / tenant model; per-tenant Enterprise SSO (SAML and OIDC) with self-service IdP setup; SCIM for user provisioning and de-provisioning; per-tenant roles and policies; and tenant-scoped audit logs. This is the pattern where the Organizations and tenants and enterprise SSO guides are required reading.
Failure mode. Bolting tenancy onto a flat B2C platform after the first enterprise deal demands SSO. Retrofitted multi-tenancy leaks: shared user pools, no per-tenant policy isolation, and SSO that an admin cannot configure without your engineers. The cost shows up as deal friction and security-review findings.
Vendor type that fits. B2B-first platforms and enterprise-readiness layers built around Organizations, SSO, and SCIM as primitives. See the B2B SaaS vertical and the multi-tenant architecture guide.
Pattern 3: Hybrid B2B2C
You serve consumers directly and you serve business tenants whose end users also log in. The mistake is collapsing both into one pool.
Consumer plane Business plane
(direct B2C users) (tenant end users)
| |
| Org A / Org B ...
| per-org SSO + SCIM
\ /
\ /
[ CIAM with two planes ]
shared primitives, separate tenancy + policy
Non-negotiable capabilities. Everything from Pattern 2, plus a clean way to run a consumer plane alongside the tenant plane without identity collisions: separate user directories or strict tenant scoping, distinct branding and flows per plane, and an authorization model that never lets a consumer identity resolve into a business tenant or vice versa.
Failure mode. One tangled user pool where a consumer who later joins a business tenant becomes two conflicting identities, or where tenant isolation depends on application code instead of the platform. Account linking and policy boundaries are the hard part.
Vendor type that fits. Platforms with a strong Organizations model that also handle high-volume B2C cleanly, or an architecture that pairs a B2B enterprise-readiness layer with a B2C platform. This is the pattern most likely to justify a two-component design; confirm the seam before committing.
Pattern 4: Regulated or self-hosted
Data residency, sovereignty, or a compliance floor (FedRAMP, HIPAA, strict in-region storage) sets the architecture before any feature does.
Your cloud / region / VPC
|
[ self-hosted or compliant-cloud CIAM ]
| | |
data stays audit / HA topology you
in-region evidence own and operate
|
identity verification / step-up where mandated
Non-negotiable capabilities. The specific compliance attestations you require, in-region or in-account data storage, exportable tamper-evident audit logs, and (often) the ability to self-host. Strong step-up and risk-based authentication are common in this pattern; see adaptive risk-based authentication.
Failure mode. Underestimating operations. Self-hosting trades a vendor invoice for on-call, patching, upgrades, and HA you own. The other failure is assuming a SOC 2 badge satisfies a FedRAMP or HIPAA requirement; the floor is specific, and the capability matrix scores each attestation separately.
Vendor type that fits. Open-source self-hosted platforms for maximum sovereignty, or compliant-cloud vendors with the exact attestations. See the open source CIAM alternatives, the government vertical, and the financial-services vertical.
Choosing between patterns
| If your situation is | Your pattern | The capabilities that decide it |
|---|---|---|
| Consumer app, high volume, cost-sensitive | B2C mobile-first | Passkeys, social, fraud signals, cost per MAU |
| Selling SaaS to companies | B2B multi-tenant | Organizations, per-tenant SSO, SCIM |
| Both consumers and business tenants | Hybrid B2B2C | Two clean planes, account linking, tenant isolation |
| Residency, sovereignty, or compliance floor | Regulated / self-hosted | Attestations, in-region data, self-host, audit |
Pin your pattern, carry its non-negotiable capability set into the vendor index, and let cost behavior and your hard constraints break the final tie. Every rating behind these recommendations is explained in the methodology.
Related vendors
Auth0
Auth0 remains the safest mid-market default for B2C plus B2B Enterprise SSO when developer velocity matters more than long-run TCO. Below 50k MAU it is hard to beat. Above 500k MAU, cost and Actions-driven lock-in make alternatives like FusionAuth (self-host), Cognito (AWS-native), or Stytch plus Corbado (passkey-first) increasingly attractive.
Amazon Cognito
Amazon Cognito is the right CIAM choice when the application is already deep in AWS and the buyer values IAM integration plus FedRAMP / PCI / HIPAA over developer velocity. Per-MAU economics are competitive with self-hosted Keycloak at the consumer scale and dramatically below SaaS competitors above 500k MAU. Outside AWS-native architectures, the DX gap relative to Auth0 / Clerk / Stytch is hard to justify.
Frontegg
Frontegg is the strongest B2B SaaS CIAM in 2026 by Admin Portal and self-service end-customer experience, the buyer is a SaaS engineering team that needs to ship enterprise-grade IT admin features without building them, and Frontegg delivers more of that out of the box than Auth0 or WorkOS. The trade-off is narrower B2C feature coverage and a smaller ecosystem than Auth0; for B2B-first SaaS the Admin Portal alone often justifies the choice.
FusionAuth
FusionAuth is the right answer when you want self-hosted CIAM without taking on Keycloak's operational weight, and want the option to switch to managed without changing vendors. Single-binary deploy, modern docs, and a genuinely usable Community tier make it the practical default for self-host evaluations in 2026, particularly for B2C and mid-market B2B SaaS that don't need FedRAMP or Zanzibar-style FGA.
Keycloak
Keycloak is the de-facto open-source CIAM in 2026 and remains the right choice when data sovereignty, on-prem deployment, or zero per-MAU cost are non-negotiable. The trade-off is operational cost, running Keycloak well is closer to running PostgreSQL than running an SDK, and teams without that capacity should reach for FusionAuth (lighter ops) or a SaaS instead.
Stytch
Stytch is the strongest passkey-first CIAM in 2026 by orchestration quality, not raw feature count. Twilio acquired it on October 30, 2025; the product runs as a Twilio subsidiary with its own API surface, SDK family, and pricing, distinct from Twilio Verify. Post-acquisition the platform combines Stytch's modern auth with Twilio's communications infrastructure, repositioning it as a credible Auth0 alternative for developer-focused teams. Below 500k MAU the case is strong for both B2C and B2B SaaS; beyond that, gaps on FedRAMP, FGA, and adaptive MFA depth narrow it.
Supabase Auth
Supabase Auth is the right CIAM choice for B2C apps and developer-tools already on the Supabase platform, Auth integrates with PostgreSQL Row-Level Security in a way that no other CIAM matches, removing the need for a separate authz vendor for many use cases. The trade-off is a B2C-first product without first-class B2B Organizations or SAML; for B2B SaaS, look elsewhere. For greenfield Supabase-native apps, Supabase Auth is one of the strongest picks at low cost.
WorkOS
WorkOS is the strongest B2B-first CIAM in 2026 by deliberate scope choice, every product surface assumes the buyer is selling to enterprise IT, not to consumers. AuthKit's 1M MAU free tier makes it a credible Auth0 alternative for B2B SaaS that doesn't need adaptive risk or B2C consumer flows. For pure B2B SSO, SCIM, and audit logs, WorkOS is hard to beat at any price point.
FAQ
- Can one platform serve more than one of these patterns?
- Yes, several can, but check the seams. A platform strong at B2B Organizations can usually also do flat B2C, and a few do hybrid B2B2C cleanly. The risk is the reverse: a B2C-first platform asked to grow real B2B tenancy, SSO, and SCIM tends to express those as add-ons rather than primitives, and the gaps show up under enterprise procurement.
- Do I need to pick the architecture before the vendor?
- Pick the pattern first. The pattern tells you which capabilities are non-negotiable (Organizations and SCIM for B2B, cost-per-MAU and passkeys for B2C, residency and self-host for regulated), and that capability set is what narrows the vendor list. Choosing a vendor first tends to bend your architecture toward what that vendor happens to do well.
- Where do passkeys fit across these patterns?
- Passkeys are primary-auth in all four, but they matter most in B2C mobile-first, where conversion and phishing resistance are direct business metrics. In B2B and regulated patterns they are increasingly a compliance and security expectation. Synced passkeys give consumer-grade UX at AAL2; device-bound passkeys give higher assurance with more operational overhead.
- How does agentic identity change these architectures?
- It adds a fourth principal type. Until recently you modeled users, tenants, and machine-to-machine clients. AI agents acting on behalf of a user need scoped, attenuated tokens distinct from the user's own session, plus an audit trail that separates agent actions from human actions. In each pattern below, treat agent identity as a first-class principal rather than reusing a user or service token.
Sources
- CIAM Compass vendor index and capability matrix
- FIDO Alliance passkey and AAL guidance
- OAuth 2.1 and OpenID Connect specifications
- SCIM 2.0 (RFC 7643 / 7644)