Identity & Access · Chapter 2
Federation, SSO, SAML and OIDC
The acronym soup, deflated. Four ideas, and you only need one mental model.
Single sign-on means you authenticate once, to one system, and other systems trust that system's word about who you are. The system doing the vouching is the identity provider (Okta, Entra ID, Ping, Google); the systems trusting it are service providers or relying parties.
Everything else is the format of the note being passed. SAML is the older XML-based format, still dominant in enterprise applications. OIDC is the newer JSON-based one built on OAuth 2.0, standard for anything modern or mobile. They solve the same problem and you will meet both for years.
The distinction that actually matters in interviews and reviews
OAuth is not authentication. OAuth 2.0 is a delegated authorisation protocol — it lets an application act on a resource on your behalf. It was widely misused as a login mechanism, which is precisely why OIDC exists: it is a thin identity layer on top of OAuth that adds an ID token making an actual claim about who the user is. If someone tells you they authenticate users “with OAuth”, ask whether they mean OIDC, because the difference has produced real vulnerabilities.
What to check in any federation setup
- Signature validation and the trust anchor. An assertion nobody verifies is an assertion anyone can forge. Check certificate expiry too — it is a recurring self-inflicted outage.
- Audience and recipient restriction. An assertion minted for one service must not be replayable at another.
- Clock skew and assertion lifetime. Long-lived assertions are replayable.
- What happens at logout. Single logout is frequently unimplemented, so sessions survive at the service provider after the user is disabled centrally — a common and genuinely dangerous gap.
- The break-glass account that bypasses the IdP. It should exist, because an IdP outage otherwise locks out everyone including administrators; it must be heavily monitored, because it is the obvious target.