SSO and Federation
Single sign-on lets an employee authenticate once to an identity provider and reach many applications without separate passwords, and federation extends that trust across organizational boundaries. Done right, SSO shrinks the password attack surface and centralizes control; done wrong, it makes the identity provider a single, catastrophic point of failure.
This topic covers SAML- and OIDC-based SSO, the trust relationships behind them, and what happens when the identity provider itself is the target — because concentrating identity concentrates risk as much as it concentrates control.
The SSO Value
One strong authentication to the identity provider, then short-lived assertions or tokens to each app: fewer passwords for users to reuse or lose, central enforcement of MFA, one place to audit access, and — the biggest operational win — instant deprovisioning when someone leaves. Disable one IdP account and access to every connected app is cut at once.
SAML and OIDC as Federation Protocols
SAML, using signed XML assertions, dominates enterprise application SSO; OIDC, using JSON and JWTs (the previous topic), is the modern standard for web and mobile. Both let a relying party trust an identity provider to vouch for the user, so the app never handles the password itself — it trusts a signed statement that the IdP has authenticated this person.
The Assertion Trust
The app trusts a signed assertion from the IdP, which means the signature validation is the whole security boundary. Weak validation — XML signature-wrapping in SAML, algorithm confusion in OIDC (Chapter 3's JWT topic) — lets an attacker forge an assertion and become anyone. The "golden SAML" attack does exactly this: with the IdP's signing key, an attacker mints assertions for any user in any connected app.
The IdP as Single Point of Failure
SSO concentrates risk. Compromise the identity provider, or an administrator's IdP session, and you get every connected app at once — which is why the IdP deserves the strongest phishing-resistant MFA and the tightest monitoring you run. The flip side of "one place to control access" is "one place to lose all of it," and the failure mode to watch is orphaned local accounts and app-level backdoors that survive an IdP disable.
- Weak or missing signature validation on SAML assertions or OIDC tokens, enabling assertion forgery and full impersonation.
- Protecting the IdP no better than a normal app, when it is the master key and needs phishing-resistant MFA and heightened monitoring.
- Leaving local or break-glass accounts on apps that bypass SSO, so deprovisioning through the IdP does not actually cut access.
- Over-trusting the network location of the IdP callback instead of validating the assertion cryptographically.
- Issuing long-lived assertions that never require re-authentication, so one login lasts all day across every app.
- Centralize authentication on one IdP, enforce phishing-resistant MFA there, and make it the most-monitored system you run.
- Validate assertion and token signatures strictly, and pin the expected algorithm and IdP keys.
- Wire deprovisioning to the IdP and audit for app-level accounts that bypass SSO.
- Use short-lived assertions and re-authentication for sensitive actions rather than one login that lasts all day.
- Provision users with SCIM so accounts are created and removed centrally, not by hand per app.
Knowledge Check
What is the biggest operational security win of SSO?
- Disabling one IdP account cuts access everywhere
- Each app can now store its own copy of the password
- Users no longer need any form of MFA on the identity provider
- It makes the identity provider impossible to attack
Why does SSO make the identity provider a critical asset?
- Compromising the IdP or its signing key unlocks every app
- The IdP stores every application's source code
- The IdP is the only system that can be encrypted
- Losing the IdP only affects brand-new logins, never the existing ones
An org rolls out SSO but leaves local login enabled on several apps. Why does this undercut it?
- Deprovisioning through the IdP won't remove the local accounts, so disabled users still get in
- Local accounts make SAML assertions load faster
- SSO cannot function at all if any local login exists
- Local accounts automatically get stronger MFA
You got correct