When you click "Sign in with Google", the app you're using never learns your Google password. It bounces you to Google, Google checks who you are, and then hands the app a sealed note saying "yes, this is really them." The app trusts the note and lets you in.
That's Federated Identity: your application stops being in the password business and instead delegates the whole job of proving who someone is to a trusted identity provider.
The problem
Building your own authentication is a liability factory. You have to store passwords securely (and inevitably someone gets the hashing wrong), handle resets, MFA, lockouts, and breach response. Every app that does this is one more honeypot for attackers.
It's also miserable for users, who end up with yet another password to forget. And for enterprises it's a non-starter: a company wants employees to use their existing corporate account, with central control to grant and — critically — revoke access when someone leaves. Reimplementing all of that, per app, is wasteful and dangerous.
AppEach app runs its own authentication and password handling.
Password StoreA separate credential store per app — duplicated and a fresh breach target.
How it works
Instead of authenticating users itself, your app redirects them to a trusted identity provider (the IdP — Google, Microsoft Entra ID, Okta, an enterprise directory). The IdP does the hard part: it verifies the user's credentials, applies MFA, whatever its policies require.
On success, the IdP issues a signed security token containing claims — assertions like who the user is and what they're allowed to do. The user carries that token back to your app, which validates the signature and claims and, finding them trustworthy, grants access. Your app never touches the password; it only ever has to trust the token. The diagram below traces the user bouncing through the identity provider and returning with a verified token the app accepts.
- UserRedirected to the IdP to prove who they are — the app never sees the password.
- Identity ProviderTrusted authority that verifies the user and issues a signed token.
- Your AppRelying party that validates the token's signature and claims, then grants access.
Validate the whole token, not just the signature. A valid signature only proves the token is genuine. You must also check it was issued by your trusted IdP (the issuer), minted for your app (the audience), and hasn't expired. Skipping the audience or expiry check is how a perfectly real token gets replayed against the wrong service.
Single sign-on and trust
Because many apps can trust the same IdP, a single login unlocks all of them — that's single sign-on (SSO). Sign in once with your work account and your email, your chat, and your dashboards all just open. The reverse is just as valuable: deactivate the account at the IdP and access to every connected app disappears at once.
The entire model rests on trust in the token. Each app is a relying party that has agreed to honor tokens from a given issuer. Get the validation right and a single, well-secured IdP protects your whole estate. It pairs neatly with an API gateway, which is an ideal chokepoint to verify tokens before requests ever reach your services, and it keeps those services cleanly stateless, since identity rides along in the token rather than in server-side sessions.
When to use it
Use federated identity for almost any real application with users — and especially when you need SSO, social login, or integration with enterprise/corporate accounts. It's the default, sane choice: let specialists run the identity infrastructure while you focus on your product.
The main caution is that you take on a critical external dependency: if the IdP is down or misconfigured, logins fail, so choose a reliable provider and handle outages gracefully. The one place to think twice is a fully closed, offline system with no external users and no SSO needs — there, a simple local auth scheme may be all the complexity you can justify.