Identity Federation: One Login for Many Services

WHY IT EXISTS Managing user accounts is a liability. Every application that stores passwords creates another target for attackers and another credential for users to forget or reuse. Identity federation solves this by centralizing authentication, allowing applications to delegate the messy and risky business of verifying who a user is.

THE MENTAL MODEL Think of identity federation like using your driver's license. A trusted authority (the DMV, your Identity Provider or IdP) issues you an ID. Other organizations (bars, airports, your Service Providers or SPs) trust that ID to verify your identity and attributes (like age) without needing to issue their own card. They trust the DMV's decision.

HOW IT WORKS A typical flow involves three parties: the user, the Service Provider (SP, the app you want to use), and the Identity Provider (IdP, the system that knows your password). When you try to log into the SP, it redirects you to the IdP. You authenticate with the IdP (e.g., with your Google password). The IdP then sends a cryptographically signed assertion back to the SP saying, "I've verified this user, and here are their attributes." The SP trusts this assertion because it's from a pre-configured, trusted IdP, and logs you in.

WHEN TO USE IT Use federation for corporate Single Sign-On (SSO), allowing employees to log in once to access many tools like Salesforce, Slack, and AWS. It's also the mechanism behind consumer "social logins" like "Sign in with Apple/Facebook/GitHub," where a user can access a new app without creating a new password. It's essential for B2B scenarios where users from one company need access to another's systems.

WHEN NOT TO USE IT For a simple, standalone application with no external integrations, setting up federation can be overkill. If your service has extreme data sovereignty or security requirements that forbid reliance on any external system for authentication, you might need to manage identities yourself. Be aware that if the central IdP goes down, it can cause a widespread outage for all connected applications.

ONE CANONICAL EXAMPLE Using your corporate Okta account to log into AWS. You navigate to the AWS console, which redirects you to your company's Okta login page. After you authenticate with Okta, you are redirected back to the AWS console and granted access to the roles and permissions associated with your Okta identity. AWS never sees your password; it only trusts the assertion from Okta.