Federated Identity Explained: SAML, OAuth, OpenID Connect and How They Fit Together

Back in 2006, I was leading an integration project between a hospital system and three insurance providers. Each organization had its own user directory, its own authentication system, and its own very strong opinions about who should be the “source of truth” for identity. Nobody was willing to hand over their user database. Nobody was willing to create accounts in someone else’s system. The project was deadlocked for two months.

Then someone on my team suggested federation. Let each organization keep its own identities, but establish trust relationships so they could vouch for each other’s users. That project shipped six months later, and it fundamentally changed how I think about identity architecture.

Federated identity is the pattern that makes modern cross-organizational access possible. It’s how you log into a SaaS application with your corporate credentials. It’s how a university researcher in Michigan can access computing resources at a national lab in Tennessee. And it’s powered by a stack of protocols that confuse even experienced engineers.

Let me untangle it.

What Federated Identity Actually Means

Federation, in the identity context, means establishing trust between independent security domains so that users authenticated in one domain can access resources in another without creating new accounts or sharing credentials.

The critical insight is that federation separates the act of authenticating a user (proving who they are) from the act of authorizing access (deciding what they can do). The user’s home organization handles authentication. The resource provider handles authorization. Trust glues them together.

This is fundamentally different from the older model where every application maintained its own user database. That model requires credential synchronization, leads to password sprawl, and creates a nightmare when someone leaves the organization. I’ve written about the distinction between authentication and authorization in detail – it’s worth understanding before diving into federation protocols.

The Three Protocols You Need to Understand

There are three protocols that dominate federated identity: SAML 2.0, OAuth 2.0, and OpenID Connect. They overlap in confusing ways, they solve different problems, and picking the wrong one for your use case will cause pain.

SAML 2.0: Enterprise Identity Federation

SAML (Security Assertion Markup Language) was ratified in 2005 and it shows. It’s XML-based, uses heavyweight digital signatures, and requires careful metadata exchange between parties. It is also, after twenty years of production deployments, the most widely supported enterprise federation protocol in existence.

SAML defines three roles:

• Identity Provider (IdP): Issues authentication assertions
• Service Provider (SP): Consumes assertions and grants access
• Principal: The user being authenticated

The core flow works like this: a user tries to access a service provider. The SP redirects to the IdP. The IdP authenticates the user and sends back a signed XML assertion containing the user’s identity and attributes. The SP validates the signature, extracts the identity, and creates a session.

Where SAML shines is in enterprise-to-enterprise federation and enterprise-to-SaaS integration. When a Fortune 500 company wants their employees to log into Salesforce or Workday with corporate credentials, SAML is usually the answer.

Where SAML struggles is in mobile applications, single-page web apps, and API-to-API authentication. It was designed for a world of server-rendered web pages and browser redirects. It works poorly outside that context.

OAuth 2.0: Delegated Authorization

Here’s where the confusion starts. OAuth 2.0 is not an authentication protocol. I need to say that loudly because I’ve watched entire teams build authentication systems on OAuth and then wonder why things went sideways.

OAuth 2.0 is an authorization framework. It answers the question “should this application be allowed to access this resource on behalf of this user?” It does NOT answer the question “who is this user?”

The classic OAuth scenario: you want a third-party calendar app to read your Google Calendar. You don’t want to give the app your Google password. So instead, you authorize the app through Google’s OAuth flow, and Google gives the app a scoped access token that lets it read (but not delete) your calendar events.

OAuth defines four roles:

• Resource Owner: The user who owns the data
• Client: The application requesting access
• Authorization Server: Issues tokens after the resource owner consents
• Resource Server: Hosts the protected resources

The flows (called “grant types”) include the Authorization Code flow, the Implicit flow (now deprecated for good reason), Client Credentials (for machine-to-machine), and others. The Authorization Code flow with PKCE is the recommended approach for most modern applications.

So why do people keep saying OAuth handles authentication? Because in practice, the access token lets you call a /userinfo endpoint to get the user’s identity. It works, technically. But it’s an ad-hoc pattern with security gaps that OpenID Connect was specifically created to fill.

OpenID Connect: Authentication Built on OAuth

OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0. It adds exactly what OAuth was missing: a standardized way to verify a user’s identity.

OIDC introduces the ID Token – a JWT (JSON Web Token) that contains claims about the authenticated user. Unlike the OAuth access token (which is meant for resource servers), the ID Token is meant for the client application. It tells the application who logged in, when they authenticated, and how.

The OIDC flow looks almost identical to OAuth’s Authorization Code flow, but with two key additions:

1. The client requests the openid scope
2. The authorization server returns an ID Token alongside the access token

OIDC also defines a /userinfo endpoint, a discovery mechanism (.well-known/openid-configuration), and dynamic client registration. It’s a complete identity layer that learned from a decade of SAML deployments and OAuth misuse.

When to Use What: My Decision Framework

After years of implementing these protocols across different environments, here’s the framework I use:

Use SAML when:

• You’re integrating with enterprise SaaS applications (most support SAML out of the box)
• You’re federating between large organizations with existing SAML infrastructure
• Compliance requirements specifically mandate SAML
• You’re deploying to environments where XML processing is not a concern

Use OAuth 2.0 (alone) when:

• You need API-level authorization without user identity
• You’re building machine-to-machine integrations
• You need scoped, delegated access to resources

Use OpenID Connect when:

• You’re building a modern web or mobile application that needs user authentication
• You want federation that’s developer-friendly and lightweight
• You need both authentication AND authorization in the same flow
• You’re building a consumer-facing identity platform

Use SAML + OIDC together when:

• You have legacy enterprise integrations (SAML) and modern applications (OIDC) in the same ecosystem
• Your IdP supports both protocols and different SPs need different protocols

In practice, most organizations I work with end up supporting both SAML and OIDC. The IdP doesn’t care – modern identity providers like Okta, Azure AD, and Keycloak speak both fluently.

The Trust Model Under the Hood

Federation doesn’t work without trust, and trust doesn’t work without cryptography. Let me explain what’s actually happening when two organizations “federate.”

Metadata Exchange

Before any authentication can happen, the IdP and SP need to exchange metadata. In SAML, this is literally an XML document containing:

• The entity’s identifier (Entity ID)
• Endpoints for SSO, logout, and artifact resolution
• The X.509 certificates used for signing and encryption
• Supported bindings (HTTP-Redirect, HTTP-POST, etc.)

In OIDC, the equivalent is the discovery document at .well-known/openid-configuration, which lists endpoints, supported scopes, signing algorithms, and the JWKS (JSON Web Key Set) URI where public keys are published.

This exchange establishes mutual knowledge. The SP knows where to send authentication requests and how to validate responses. The IdP knows where to send assertions and what claims to include.

Certificate Trust

SAML assertions are digitally signed using the IdP’s private key. The SP validates the signature using the IdP’s public certificate, which it received during metadata exchange.

OIDC tokens are signed using the IdP’s private key (typically RS256 or ES256). The SP validates using the public key from the JWKS endpoint.

In both cases, if the signing certificate or key is compromised, an attacker can forge assertions or tokens and impersonate any user. This is why certificate management is a critical operational concern, not an afterthought.

I’ve seen organizations store their SAML signing certificates in plaintext config files checked into Git. I’ve seen OIDC token signing keys that hadn’t been rotated in three years. These are the kinds of practices that lead to the incidents that make the news.

Claims and Attributes: The Data That Flows

When an IdP authenticates a user and sends an assertion back to the SP, it includes claims (OIDC) or attributes (SAML) about the user. These typically include:

• Subject/NameID: The unique identifier for the user (email, employee ID, opaque identifier)
• Name claims: First name, last name, display name
• Email: Usually the primary identifier in SaaS integrations
• Groups/Roles: Used by the SP to determine authorization
• Custom attributes: Department, cost center, location – whatever the SP needs

Attribute mapping is where I spend a surprising amount of time during federation projects. The IdP might call it memberOf, the SP might expect groups. The IdP sends a full DN (CN=Engineering,OU=Groups,DC=corp,DC=example,DC=com), but the SP expects just Engineering. These mismatches are boring but they’ll block your deployment every time.

The Attribute Release Problem

In cross-organizational federation, there’s a genuine tension between the SP’s need for user attributes and the IdP’s obligation to protect user privacy.

A research institution might need to know that a user belongs to a specific department. But should they also get the user’s phone number, home address, and employee ID? Probably not.

Thoughtful attribute release policies – where the IdP only shares the minimum attributes necessary for each SP – are a hallmark of mature federation deployments. In the InCommon federation (higher education), there’s an entire framework called REFEDS (Research and Education Federations) that standardizes attribute release categories.

Federation at Scale: Multi-Tenant and Multi-Protocol

Real-world federation gets complex fast. Let me share two patterns I see regularly.

Multi-Tenant SaaS Federation

If you’re building a SaaS application, your customers will want to federate with your application using their own IdP. This means your application needs to support potentially thousands of IdP trust relationships.

The standard approach is:

1. Each tenant configures their IdP metadata in your admin portal
2. Your application uses the tenant identifier (usually derived from the user’s email domain) to determine which IdP to redirect to
3. Each tenant’s assertions are validated against that tenant’s specific IdP certificate

This is called “IdP Discovery” and it’s the flow you see when an application asks for your email address before redirecting you to your company’s login page.

Protocol Bridging

Many organizations need to bridge between protocols. A common scenario: your corporate IdP speaks SAML, but a partner’s API requires OIDC tokens. Rather than rebuilding your IdP, you deploy a protocol bridge (sometimes called a Security Token Service) that accepts SAML assertions and issues OIDC tokens.

Most modern identity platforms handle this natively. But I’ve worked in environments where we had to build custom bridges, and it’s tricky work. You’re translating between different trust models, token formats, and session semantics.

Security Risks in Federated Environments

Federation introduces risks that don’t exist in monolithic identity systems.

Trust Chain Attacks

In a federated mesh, if Organization A trusts Organization B, and Organization B trusts Organization C, does Organization A trust Organization C? The answer should be no (federation trust is not transitive), but I’ve seen misconfigurations where it effectively became yes.

Token Replay and Substitution

An attacker who intercepts a SAML assertion or OIDC token can potentially replay it against the SP. Mitigations include short token lifetimes, audience restrictions, and nonce validation.

IdP Compromise

If a federated IdP is compromised, the attacker can mint assertions for any user, against any SP that trusts that IdP. This is the scenario that played out in the Golden SAML attacks. The only defense is defense in depth: monitor for anomalous assertion patterns, enforce MFA at the IdP, and assume any single layer can fail.

For a comprehensive approach to mitigating these risks, I’ve laid out my thinking on Zero Trust Security architectures – the philosophy that trust should be continuously verified, never assumed, even within federated relationships.

Building Federation Into Your Architecture

If you’re designing an identity architecture today, here’s my advice:

Start with OIDC for new applications. It’s modern, developer-friendly, and has strong library support in every major language. Don’t use SAML for new builds unless you have a specific reason.

Support SAML for enterprise integration. Your enterprise customers will ask for it. Their IdPs support it. Don’t fight this battle.

Centralize your IdP. Even if you support multiple protocols, authentication decisions should flow through a single identity platform. This gives you one place to enforce MFA, one place to monitor for anomalies, and one place to revoke access.

Treat federation metadata as infrastructure. Automate metadata exchange, monitor certificate expiration, and test federation health continuously. The number of outages I’ve seen caused by expired SAML certificates is embarrassing for the industry.

Plan for the user journey, not just the protocol. Federation is ultimately about human beings getting access to things they need. Map the complete user experience – including error states, account linking, and first-time access flows – before you start writing configuration.

The Future of Federation

Federation isn’t going away, but the protocols are evolving. The big trends I’m watching:

Verifiable Credentials and decentralized identity (based on W3C standards) promise a world where users carry their own cryptographic credentials without depending on a centralized IdP. It’s early, but the architecture is sound.

Continuous Access Evaluation Protocol (CAEP) and Shared Signals Framework (SSF) allow IdPs and SPs to share real-time risk signals, enabling faster revocation and more dynamic access decisions.

Passkeys and FIDO2 are changing the authentication that happens before federation. When the IdP authenticates a user with a hardware-bound cryptographic credential instead of a password, the entire federation chain becomes stronger.

For anyone building SSO systems today, my recommendation is to build on OIDC, support SAML where needed, and keep an eye on verifiable credentials. The organizations that get identity federation right will have a massive advantage as the boundary between “internal” and “external” continues to dissolve.

Federation is hard. It’s political, it’s technical, and it requires sustained operational attention. But it’s also the only pattern that scales across organizational boundaries without forcing everyone into a single identity silo. That’s why I’ve spent twenty years building these systems, and why I still think federation is one of the most important patterns in enterprise architecture.