What is identity federation, and what role does an identity provider play?
Short answer
Identity federation establishes trust between an identity provider (IdP) that authenticates users and service providers (relying parties) that consume that authentication. The IdP verifies the user and issues a signed assertion or token; the service provider trusts it instead of managing its own credentials. This enables cross-domain SSO and centralized control, but concentrates risk: compromise the IdP and you compromise everything that trusts it.
When a user logs into a third-party SaaS app "with their company account," that's identity federation at work. It lets organizations centralize authentication while still using many independent applications.
The players
- Identity provider (IdP). The authority that authenticates the user and issues proof of identity — Entra ID, Okta, Google, etc. It holds the credentials and runs the login.
- Service provider (SP) / relying party. The application the user wants to reach. It does not verify credentials itself; it trusts assertions from the IdP.
- The trust relationship. Established ahead of time by exchanging metadata and signing keys, so the SP can cryptographically verify that an assertion really came from the IdP and wasn't forged.
How a federated login flows
The user hits the SP, which redirects them to the IdP. The IdP authenticates them (password + MFA, etc.) and returns a signed assertion or token (a SAML assertion or an OIDC ID token) describing who they are. The SP validates the signature, reads the claims, and grants a session — without ever seeing the user's password.
Why centralize — and what it costs
The upside is real: one place to enforce MFA and conditional access, one place to disable a departing employee, consistent identity across dozens of apps, and no password sprawl. The downside is concentration of risk — the IdP becomes a single point of catastrophic failure. Compromise it (or its signing keys) and an attacker can mint valid assertions for every connected app. That's why IdPs demand the strongest protections: phishing-resistant MFA for admins, key protection, and tight monitoring.
Federation vs. one big directory
A single directory means one system owns all the accounts. Federation lets separately-administered domains trust each other — useful for partners, mergers, and SaaS where you don't control the other side's user store.
What interviewers look for: you clearly separate IdP from relying party, you describe the signed-assertion trust model, and you flag the IdP as the concentrated risk that must be protected hardest.
Likely follow-ups
- What is the difference between the IdP and the service provider / relying party?
- Why does federation concentrate risk on the IdP, and how do you mitigate it?
- How does federation differ from simply having one big directory?