Federated Identity
Letting users log into many services with one identity from a trusted provider — the basis of SSO and 'Sign in with Google.' Centralizes credentials where they can be secured.
What is federated identity?
Federated identity lets a user authenticate once with a trusted Identity Provider (IdP) and then access many separate applications without logging in again to each. The applications — the Service Providers — trust the IdP to vouch for who the user is, so they never handle the user’s password themselves. It’s the foundation of Single Sign-On (SSO) inside organizations and of consumer “Sign in with Google/Apple/GitHub” buttons. The core idea: identity is established in one place and federated out to everywhere else via trust.
How the trust works
Federated identity rests on a trust relationship carried by cryptographically signed assertions. The user hits an application (Service Provider), which redirects them to the IdP; the IdP authenticates them (password, MFA, whatever it enforces) and returns a signed assertion or token attesting to their identity; the application validates that signature against the IdP’s public key and grants access. The two dominant protocol families implement this: SAML (XML assertions, entrenched in enterprise SSO) and OpenID Connect (JSON/JWT tokens built on OAuth 2.0, dominant for modern web and mobile). The security payoff is structural: credentials live in exactly one place — the IdP — rather than being created and stored separately by every app. That means one place to enforce strong authentication and MFA, one place to monitor for compromise, and critically, one place to revoke access — deprovisioning a departing employee at the IdP cuts them off from every federated app at once, instead of hunting down dozens of individual accounts.
Why it matters — and where the risk concentrates
For organizations, federation is both a security and an operational win: users manage fewer passwords (less reuse, less phishing surface), IT manages access centrally, and onboarding/offboarding become single actions. It’s the backbone of enterprise identity (Okta, Azure AD/Entra ID, Ping) and of the broader move toward zero-trust and identity-as-the-perimeter. But centralization cuts both ways: the IdP becomes a high-value single point of failure and attack. If the IdP is down, users can’t log into anything; if the IdP is breached, an attacker potentially gets everything. This is why IdPs demand the strongest protection — hardened MFA, careful session management, monitoring — and why assertion validation on the Service Provider side (verifying signatures, audience, and expiry) matters so much: the whole model’s safety depends on that trust not being forgeable.
What people get wrong
- Treating the IdP as ordinary infrastructure — it’s the keys to every federated app; it needs the strongest MFA and monitoring you have.
- Weak assertion validation on the app side: if Service Providers don’t rigorously verify signatures, forged identities defeat the whole scheme.
- Forgetting availability — a down IdP locks users out of everything; federation concentrates both convenience and single-point-of-failure risk.
Primary source: NIST SP 800-63C: Federation
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.