Chapter 10: Single Sign-On at Scale — Identity as Infrastructure

This is Part 10 of a chapter-by-chapter walkthrough of my book OpenID: Modern Identity for Developers and Architects. In the previous chapter we hardened the client side. Chapter 10 pulls back to the enterprise view: running identity for an entire organization.

10.1 — Corporate Identity Providers

Enterprise identity used to mean Active Directory on-premises. Today it's mostly a hybrid: AD still anchoring the on-premises world, synced up to Microsoft Entra ID (formerly Azure AD) for cloud apps, with Okta or Auth0 often sitting in front for customer-facing scenarios. The architecture that matters isn't which product you chose — it's how you've drawn the federation lines, where policy lives, and who's the system of record for any given user.

Chapter 10 walks through the corporate-IdP pattern: a directory as the source of truth, one or more identity protocols (SAML, OIDC, OAuth 2.0) for app integration, a policy engine for conditional access, and the tradeoffs between keeping everything centralized versus federating out to partner organizations.

10.2 — The CIAM and SSO Vendor Ecosystem

Okta, Auth0, Entra ID, Ping, ForgeRock, Keycloak — evaluating this space gets expensive fast if you don't know what you're actually buying. The build-vs-buy question is more nuanced than "Okta is expensive, let's build it ourselves" (you won't — not at the security posture you think you can). The chapter walks through the feature criteria that actually matter (legacy protocol support, data residency, device trust, developer ergonomics) and how to compare costs honestly — per-user fees plus transaction fees plus implementation plus the hidden cost of operational burden you never quite anticipated.

10.3 — Multi-Tenant Design

Tenant isolation is non-negotiable. Users from one tenant must never access another's data, ever, under any failure mode. That means tenant-aware token validation, row-level security in the database where possible, tenant discovery mechanisms that route correctly (email-domain mapping, subdomain, a lookup service), and per-tenant IdP configuration so each customer can plug in their own OIDC/SAML provider.

10.4 — Account Linking

Users don't authenticate through one provider; they authenticate through three. Their corporate IdP for work, social login for the website, a legacy account from before the migration. Account linking is how you recognize those as the same person — and it's one of the more dangerous features you can ship if you don't design it deliberately. Email-based linking is convenient and insecure (takeovers across providers). Explicit user-initiated linking is more work but safer. Chapter 10 walks the tradeoff and the right path for each context.

10.5 — External User Access

Employees aren't the only users. Partners, contractors, vendors, and customers all need access — each with different trust models. B2C patterns (self-registration, social login, progressive profiling) and B2B guest access (restricted permissions, expiration, enhanced audit) look similar on the surface but are architecturally distinct. Mixing them up is how "shadow access" creeps into an organization.

What Chapter 10 Sets Up

After Chapter 10 you should see identity as infrastructure rather than "the login feature." Everything that follows — MFA, lifecycle management, threat modeling, FAPI, Zero Trust — is about operating that infrastructure at organizational scale.

Next up — Chapter 11: MFA and Conditional Access. SSO concentrates authentication risk; MFA and risk-based step-up disperse it. We cover TOTP, push, hardware keys, the three MFA factors, and how acr and amr claims let OIDC applications reason about authentication strength.