5.6.2. Federation and Single Sign-On (SSO)

💡 First Principle: Federation allows organizations to trust each other's authentication — a user authenticated by Organization A can access resources in Organization B without creating a separate account. SSO lets a user authenticate once and access multiple applications without re-entering credentials. Both reduce password fatigue and improve user experience, but both require careful implementation.

Federation — trust between identity providers across organizational boundaries. A university student logs in with their university credentials and accesses cloud services, learning platforms, and library resources from different providers — all without separate accounts. Standards: SAML, OAuth, OpenID Connect.

SAML (Security Assertion Markup Language) — XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). Common in enterprise web applications.

Loading diagram...

OAuth — authorization framework (not authentication) that allows third-party applications to access resources without sharing credentials. When an app says "Sign in with Google," it's using OAuth to get an access token.

OpenID Connect (OIDC) — authentication layer built on top of OAuth. Adds an identity token that proves who the user is, complementing OAuth's authorization.

SSO — a centralized authentication service where a single login grants access to multiple applications. Reduces password fatigue but creates a single point of failure — if SSO is compromised, all connected applications are exposed. Must be protected with MFA.

⚠️ Exam Trap: OAuth is for authorization (what can you access?), not authentication (who are you?). OpenID Connect adds authentication on top of OAuth. SAML handles both authentication and authorization. If a question asks specifically about authorization, OAuth is the answer.