Federated Identity Pattern
Delegate authentication to external identity providers: SAML, OIDC, SSO flows, identity federation across organizational boundaries.
What Is Federated Identity?
Federated identity is an architectural pattern in which a system delegates authentication to a trusted external party — an Identity Provider (IdP) — rather than managing credentials itself. The application, called the Service Provider (SP) or Relying Party (RP), trusts the IdP to assert who the user is, freeing the application from storing passwords, handling MFA, or enforcing password policies.
This pattern is the backbone of Single Sign-On (SSO): a user authenticates once with the IdP and is granted access to multiple service providers without re-entering credentials. Common real-world IdPs include Auth0, Okta, Azure Active Directory (Azure AD / Entra ID), Google Identity, and AWS Cognito.
Core Protocols
| Protocol | Format | Typical Use Case | Token Type |
|---|---|---|---|
| SAML 2.0 | XML assertions | Enterprise SSO, B2B federation | XML Assertion |
| OpenID Connect (OIDC) | JSON/JWT | Consumer & cloud-native apps | ID Token (JWT) |
| OAuth 2.0 | JSON | Delegated authorization (not identity) | Access Token |
| WS-Federation | XML | Microsoft ecosystems, legacy enterprise | XML Token |
OIDC vs OAuth 2.0
OAuth 2.0 answers 'what can this app do on your behalf?' — it is an authorization framework. OpenID Connect is a thin identity layer on top of OAuth 2.0 that answers 'who are you?' — it is an authentication protocol. In most modern systems, you use OIDC for login and OAuth 2.0 access tokens for API authorization.
The OIDC / SSO Flow
Cross-Organizational Federation
When two organizations need to share access — for example, a company allowing its enterprise customer's employees to log in — they establish a trust relationship between IdPs. This is called identity federation or B2B federation. The typical flow is:
- Organization A (customer) has their own IdP (e.g., Azure AD).
- Organization B (SaaS vendor) configures its IdP (e.g., Okta) to trust Organization A's IdP as an external identity source.
- When a user from Organization A accesses Organization B's app, they are redirected to their own IdP for authentication.
- Organization A's IdP issues a SAML assertion or OIDC token to Organization B's IdP, which maps it to a local user account.
- Organization B's IdP issues a token to the application.
Architecture Diagram
Key Design Decisions
| Decision | Options | Recommendation |
|---|---|---|
| Protocol choice | SAML vs OIDC | Prefer OIDC for new builds; support SAML for enterprise customers who require it |
| Session management | IdP-managed vs SP-managed sessions | SP manages short sessions; IdP handles revocation via backchannel logout |
| Just-in-time provisioning | Pre-provisioned vs JIT | JIT provisioning on first login reduces admin overhead for large enterprises |
| Attribute mapping | Static vs dynamic claim mapping | Map IdP claims to local roles dynamically via claim transformation rules |
| Token storage | Cookie vs localStorage | HttpOnly, Secure, SameSite=Lax cookies — never localStorage for sensitive tokens |
Security Warning: Validate Every Token
Never trust an ID token without validating its signature (using the IdP's public JWKS), issuer (`iss` claim), audience (`aud` claim), and expiry (`exp` claim). Skipping any of these validations opens your system to token substitution attacks.
Interview Tip
When asked about SSO or federated identity in an interview, walk through the OIDC Authorization Code flow step by step. Interviewers want to see that you understand the back-channel token exchange (why the code is exchanged server-side rather than returning tokens directly to the browser) and that you know the difference between authentication (OIDC) and authorization (OAuth 2.0 scopes). Mention PKCE for public clients.