7.5 Single Sign-On and Identity Basics
Why Federate at All
Every application that holds its own credential store is another database to breach, another password to reuse, and another place users pick Spring2026!. Single sign-on flips the topology: a central identity provider (IdP) authenticates the user once, and every downstream application (service provider, or SP) trusts a signed statement from the IdP instead of a password. Users see one login, IT enforces one MFA policy and one phishing-resistant standard, and joiner-mover-leaver changes take effect at a single choke point rather than in N disconnected directories.
SAML 2.0: A Signed XML Envelope
The enterprise workhorse is browser-redirect and still everywhere. In an SP-initiated flow the user hits the app, the app redirects the browser to the IdP with an authentication request, the user authenticates (and second-factors) at the IdP, and the IdP POSTs a signed XML assertion back to the app’s assertion-consumer service. The assertion carries an AuthnStatement (how and when the user authenticated), attribute claims, an audience restriction naming the SP, and short validity conditions. The SP validates the XML signature against the IdP certificate it pinned out-of-band — the password never transits, and never touches the app at all.
OIDC: OAuth 2.0 Grows an Identity Layer
OpenID Connect rides on the OAuth 2.0 authorization-code flow, modernized with PKCE: the app redirects to the IdP’s authorize endpoint, the user consents, an ephemeral code returns over the front channel, and the app swaps it on the back channel for tokens. The ID token is a signed JWT asserting identity — iss, aud, sub, expiry, and profile claims — while the access token is a separate bearer credential scoped for API calls. Tokens are short-lived and refreshed, apps are registered with exact redirect URIs, and native and web clients never see the password.
The Hub Becomes the Crown Jewel
Consolidation concentrates risk: one IdP session compromise is every application at once. So put phishing-resistant factors (passkeys, hardware keys) on the IdP itself, not the spokes; keep SSO sessions short and re-checked; pin IdP signing certificates and rotate them; scope redirect URIs exactly; and deprovision through SCIM so departures lose all spokes the day they leave. Watch the admin lane too — global admin roles and API tokens on the identity tenant are themselves SSO-equivalent, which is why identity providers are now a primary target of threat actors.
Architecture Diagram
Key Takeaways
- SSO replaces N credential stores with one: apps consume signed assertions, and passwords never reach them.
- SAML asserts identity via a signed XML document with audience restrictions, validated against a pinned IdP certificate.
- OIDC issues a signed JWT ID token over an authorization-code + PKCE exchange, with short-lived API access tokens.
- The IdP is now the crown jewel: phishing-resistant MFA, short sessions, and SCIM deprovisioning belong there.
- Centralization cuts password-reuse surface, which is exactly why breach-and-attack simulation now targets identity tenants first.