Federated Identity
Federated identity lets a user authenticate with one identity provider and use that identity to access multiple services — without each service managing passwords. "Sign in with Google" and enterprise SSO (Okta, Azure AD) are federated identity. Standards: SAML (enterprise), OIDC (modern web), OAuth (delegated access). The benefit: one strong identity, many relying services; password fatigue and reuse disappear.
Foundational.
How it works
Federated identity is the pattern where authentication is delegated to a trusted Identity Provider (IdP), and other services (Service Providers, SP, or Relying Parties, RP) trust the IdP's assertion instead of authenticating the user themselves.
The cast:
- Identity Provider (IdP): Google, Okta, Azure AD. Authenticates the user, issues identity assertions.
- Service Provider / Relying Party (SP / RP): your app. Trusts the IdP's assertion, grants access.
- User: authenticates once with the IdP; accesses many SPs.
The flow: user tries to access an SP. The SP redirects to the IdP. The user authenticates with the IdP (or has an existing session). The IdP redirects back to the SP with an assertion (a signed token) saying "this is user X." The SP trusts the assertion and grants access.
Three standards implement this: SAML (enterprise, XML-based), OIDC (modern web, JWT-based), and OAuth (technically authorization, but often combined).
Three standards implement federated identity:
SAML 2.0 (enterprise, 2005): XML-based assertions, signed with XML signatures. Heavyweight but battle-tested. Used by Okta, Azure AD, Ping for enterprise SSO. Strength: mature, supported by every enterprise IdP. Weakness: XML signatures are notoriously easy to get wrong (XML signature wrapping attacks); hard to implement correctly.
OpenID Connect (OIDC) (modern web, 2014): thin layer on OAuth 2.0. Adds an ID token (a JWT) that asserts the user's identity. Lightweight, JSON-based, easy to implement with modern libraries. The standard for consumer-facing SSO (Google, Microsoft, Apple).
OAuth 2.0 (technically authorization, often combined): OAuth provides delegated access (access tokens); OIDC adds identity (ID tokens). Most "Sign in with X" flows use OAuth + OIDC together.
For new systems, use OIDC. SAML is necessary for enterprise integrations with existing IdPs but should not be the first choice for new builds.
Federation is a trust relationship: the SP trusts the IdP to authenticate users correctly and to assert their identity accurately. This trust is bilateral — the SP must be configured to trust a specific IdP, and the IdP must be configured to issue assertions for that SP.
Trust configuration:
- IdP publishes its signing certificate. The SP uses it to verify assertion signatures.
- SP registers a redirect URI / audience with the IdP. The IdP only issues assertions for that audience.
- Optional: attribute mapping. The IdP sends claims (email, name, groups); the SP maps them to local user attributes.
The IdP is a high-value target. If compromised, the attacker can impersonate any user to any SP that trusts the IdP. This is why enterprise IdPs (Okta, Azure AD) have such strict security: MFA for admins, hardware keys, anomaly detection, session monitoring.
SPs must validate every assertion: signature valid, audience matches, expiry not passed, issuer trusted. Skipping any check creates vulnerabilities (assertion injection, replay attacks).
If you're integrating with an existing enterprise customer who already uses Okta or Azure AD, you'll likely need SAML — it's what those IdPs speak. If you're building a consumer product with "Sign in with Google/Apple/Microsoft," use OIDC. If you're a B2B SaaS supporting both, build for OIDC and add SAML via a bridge (Auth0, WorkOS) — implementing SAML correctly from scratch is painful and bug-prone. The general trend: OIDC for new systems, SAML maintained for legacy enterprise integration, with bridges translating between them.
Benefits of federated identity:
- One identity, many services: users authenticate once with the IdP; SSO across all SPs.
- Stronger authentication: the IdP can enforce MFA, hardware keys, anomaly detection — far stronger than most SPs would implement alone.
- Centralized revocation: disable a user at the IdP; they lose access to all SPs.
- Reduced password fatigue: one password (or no password, with passkeys) instead of one per service.
- Enterprise control: employers can provision/deprovision employees across all SaaS from one place.
Risks:
- IdP compromise = total compromise. The IdP is the keys to the kingdom.
- Privacy: the IdP sees every login across every SP. Some users object; some regulations limit data sharing.
- Vendor lock-in: switching IdPs is hard once all SPs trust one.
- Outage propagation: if the IdP is down, no one can log in to any SP. Critical dependency.
Mitigations: pick an IdP with strong security and high uptime (Google, Azure AD), enforce MFA on the IdP itself, and have a fallback for the rare IdP outage.
What's the key benefit of federated identity over per-service authentication?
Pick one answer.
Why is the IdP a high-value target in a federated identity system?
Pick one answer.
You're building a new B2B SaaS and want to let customers log in with their corporate identity. Some customers use Okta (SAML); others use Google Workspace (OIDC). What's the practical approach?
Pick one answer.
Engineering mental model
Mental model. Think of Federated Identity as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does Federated Identity mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”
Before choosing Federated Identity, name the workload, the critical user path, the dominant bottleneck, the failure you are trying to absorb, and the trade-off you are willing to accept. If you cannot name those five things, the design is probably premature.
Authorization: Bearer <access-token>
GET /v1/federated-identity
Host: api.example.comBack-of-the-envelope reasoning
Example: 10M requests/day ÷ 86,400 ≈ 116 requests/s average. Design for peak rather than average; a 10× peak is ≈ 1,160 requests/s.
Interactive thought experiment: Federated Identity
Change the variables below and predict what breaks first in Federated Identity. The production lab can later reuse these same inputs.
Change one variable at a time. Predict the failure mode first, then move the slider and see whether your mental model matches the simplified system response.
If you are stuck on Federated Identity, start by drawing the request path and marking every network hop, stateful component, queue, cache and failure boundary. Then estimate where the system will saturate.
You increase traffic by 10× in a system using Federated Identity. What should you inspect first?
Pick one answer.
Which statement is the safest engineering habit when using Federated Identity?
Pick one answer.
You have dashboards for traffic, latency, errors and saturation. You can change the architecture, but every change has operational cost.
Production scenario: your system uses Federated Identity, traffic suddenly spikes, and p99 latency doubles. What is your first move?
Interview drill
Answer this without notes: When would you choose Federated Identity, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.
For Federated Identity, define the trust boundary first. Identify who is allowed to perform each action, where credentials live, how they expire, and what a compromised credential can reach.
Numerical sanity check
A practical blast-radius question: if one credential is compromised, how many users, services, records or regions could it affect? Prefer designs where that number is deliberately bounded.
Do not optimize for a memorized definition. Reason from the workload and failure mode.
What is the smallest trust boundary you would enforce for Federated Identity, and what would you log so a suspicious action can be investigated later?
Pick one answer.
What you gain, what you pay
- +One identity across many services — no password fatigue.
- +IdP can enforce stronger authentication than each SP alone (MFA, hardware keys).
- +Centralized provisioning/deprovisioning (one place to revoke access).
- +SPs never see the password — SP breach doesn't compromise credentials.
- −IdP compromise = compromise of all SPs (concentrated risk).
- −IdP outage = no one can log in anywhere (critical dependency).
- −Vendor lock-in once SPs are configured to trust a specific IdP.
- −SAML is complex and bug-prone to implement correctly.
How this breaks in production
- IdP compromise — attacker can impersonate any user to any SP.
- IdP outage — no logins across all SPs.
- SP not validating assertion signature, audience, or expiry — assertion injection.
- SAML XML signature wrapping attacks — classic SAML implementation bug.
Don't fall into these traps
- •Implementing SAML from scratch instead of using a library/platform.
- •Not validating the assertion audience (assertion from SP-A reused against SP-B).
- •Not checking assertion expiry — replay attacks with old assertions.
- •Treating OAuth as authentication without OIDC.
Real systems using this
How real systems implement this
- Okta — Enterprise IdP supporting SAML and OIDC. Acts as the single authentication point for thousands of SaaS apps. When an employee leaves, disabling them in Okta revokes access across all apps at once.
- Google Sign-In (OIDC) — Consumer federated identity via OpenID Connect. Users authenticate with Google; third-party apps receive an ID token asserting the user's identity. The app trusts Google's signature.
Practice saying it out loud
- Q1What is federated identity? How does SSO work?
- Q2Compare SAML and OIDC. When would you use each?
- Q3Why is the IdP a high-value target, and how do you defend it?
- Q4What checks must an SP perform on every assertion?
Further reading & references
Core explanations are original NO CAP material. External references are provided for deeper study and standards.
What next?
Mark as understood once the mental model clicks.
Next recommended
Authentication