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, so they do the human thing and reuse one. That turns your security into everyone else's: when the weakest app holding that password is breached, attackers replay the stolen email-and-password pair at every other site they can find. 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.
Step through one breach below: five work apps, each with its own password store, and one of them hashes badly. When the attackers crack Maya's password, predict what they do next. Then flip the switch and replay the same breach when every app trusts one identity provider instead.
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.
Step through a sign-in below, one lane per participant, with the token's contents beside it. Before the token arrives, predict what Shop learns about Maya. Later, another app that also trusts the IdP tries to reuse her token at Shop: predict whether Shop accepts it, then switch Shop to checking only the signature and replay it.
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. Use your platform's well-tested token library for this rather than hand-rolling the checks, and make sure every one of them is switched on.
Your API accepts any token whose signature verifies against your identity provider's public key, and checks nothing else. Which attack does that leave open?
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.
An employee leaves the company. All twelve of your internal apps sign users in through the corporate identity provider. What's the fastest way to cut off their access?
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.