Demystifying Federated Identity: How OAuth2, SAML, and OIDC Actually Connect

In the early days of the web, identity was siloed. Every website maintained its own user database. This forced users to manage unique credentials for every service they accessed. As organizations grew and cloud services proliferated, this model became unsustainable. It created credential fatigue for users and a security nightmare for administrators. Federated identity emerged to solve this problem by allowing identity information to be shared securely across independent domain boundaries. Today, three standards dominate the federated identity landscape. These are Security Assertion Markup Language (SAML) 2.0, OAuth 2.0, and OpenID Connect (OIDC). While these protocols are frequently mentioned together, they serve different purposes and operate on different principles. Understanding how they function individually and how they connect is essential for designing secure, modern systems.

The Core Concepts: The Identity Dictionary

Before diving into the protocols, we must establish a clear vocabulary. Many security discussions conflate distinct concepts, leading to architectural errors.

Authentication vs. Authorization

The most fundamental distinction in identity management is between authentication and authorization.

Authentication (AuthN): The process of verifying who a user is.
Authorization (AuthZ): The process of verifying what a user is allowed to do.

It proves identity by validating credentials like passwords, biometrics, or security keys. It determines access rights and permissions to specific resources. A passport is an authentication token. It proves who you are to the border agent. A concert ticket is an authorization token. It does not care who you are, only that you have the right to enter the venue and sit in a specific section.

Federated Identity Roles

In a federated identity transaction, entities play specific roles under different names depending on the protocol.

Concept	SAML 2.0 Terminology	OAuth 2.0 / OIDC Terminology	Description
The User	Principal	Resource Owner	The entity whose identity or resources are being accessed.
The Client	User Agent (Browser)	Client Application	The software or browser making requests on behalf of the user.
The Identity Source	Identity Provider (IdP)	OpenID Provider / Authorization Server	The system that authenticates the user and asserts identity.
The Target Service	Service Provider (SP)	Relying Party (RP) / Resource Server	The application that relies on the identity or grants access to resources.

SAML 2.0: The Enterprise Heavyweight

SAML 2.0 is an XML-based open standard for exchanging authentication and authorization data. Developed in 2005, it remains the backbone of enterprise Single Sign-On (SSO) systems.

Architectural Mechanics

SAML operates by exchanging XML documents containing assertions about a user. A SAML assertion is a cryptographically signed document containing information about the user's identity, attributes, and authentication event. To establish trust, the Service Provider and the Identity Provider exchange metadata documents containing their public keys and endpoint URLs. SAML assertions are signed using XML Digital Signatures (XML-DSig). They can also be encrypted to protect sensitive attributes. This ensures that the assertion cannot be tampered with or read while in transit through the user's browser. A typical SAML assertion contains three types of statements:

Authentication Statements: Record the actual login event, including the timestamp and the method used.
Attribute Statements: Detail specific user properties, such as email address, department, and group memberships.
Authorization Decision Statements: Specify whether the user is permitted to access a particular resource.

SP-Initiated SAML Flow

The most common SAML flow is Service Provider-initiated (SP-initiated). In this flow, the user attempts to access a protected application directly, and the application redirects the user to the Identity Provider for authentication.

sequenceDiagram
    autonumber
    actor User as User Browser
    participant SP as Service Provider (SP)
    participant IdP as Identity Provider (IdP)
 
    User->>SP: Access protected resource
    SP->>User: Redirect with SAML Request (AuthnRequest)
    User->>IdP: Present AuthnRequest to IdP
    IdP->>User: Prompt for credentials / MFA
    User->>IdP: Authenticate
    IdP->>User: Generate SAML Response (signed assertion)
    User->>SP: POST SAML Response to Assertion Consumer Service (ACS)
    SP->>SP: Validate signature and issue local session
    SP->>User: Grant access to resource

SAML uses bindings to transport these messages. The HTTP Redirect Binding is typically used to send the request from the SP to the IdP via query parameters. The HTTP POST Binding is used to return the assertion from the IdP to the SP via an HTML form containing a base64-encoded payload. The browser automatically submits this payload.

Security Considerations for SAML

While robust, SAML has unique security considerations. Replay attacks are prevented using the InResponseTo attribute and strict validation of the NotOnOrAfter timestamp. The SP must verify that the assertion is sent to the correct Assertion Consumer Service (ACS) URL. Furthermore, XML parser vulnerabilities represent a major risk. Security teams must defend against XML Signature Wrapping (XSW) attacks. In these attacks, adversaries modify the XML structure to bypass signature validation while injecting malicious assertions.

OAuth 2.0: The Delegation Framework

OAuth 2.0 is not an identity protocol. It is an industry-standard framework for delegated authorization. It was designed to solve a specific problem. It allows a third-party application to access resources on behalf of a user without the user sharing their password.

Key Roles and Architecture

OAuth 2.0 defines four roles:

Resource Owner: The user who owns the data.
Client: The application making requests on behalf of the resource owner.
Authorization Server: The server that authenticates the resource owner and issues tokens.
Resource Server: The API hosting the protected data.

Unlike SAML, OAuth 2.0 does not standardize the format of its tokens. An Access Token can be a simple random string, known as a reference token. It can also be a structured token like a JSON Web Token (JWT). The Resource Server must know how to validate the token. It does this either by calling an introspection endpoint or by verifying a cryptographic signature. Refresh tokens are also supported. These allow the client to request new access tokens without requiring user interaction when the original token expires.

The Modern Flow: Authorization Code with PKCE

For public clients and confidential clients alike, the Authorization Code Flow with Proof Key for Code Exchange (PKCE) is the industry standard. PKCE protects the authorization code from interception by introducing a dynamic cryptographic challenge.

sequenceDiagram
    autonumber
    actor User as User Browser / Client App
    participant AS as Authorization Server
    participant RS as Resource Server
 
    User->>AS: Request Auth Code (includes Code Challenge)
    AS->>User: Authenticate user & consent prompt
    User->>AS: Approve consent
    AS->>User: Redirect back with Auth Code
    User->>AS: Exchange Auth Code + Code Verifier for Access Token
    AS->>AS: Validate Code Verifier against Challenge
    AS->>User: Return Access Token (and optional Refresh Token)
    User->>RS: Request resources with Bearer Access Token
    RS->>RS: Verify Access Token
    RS->>User: Return protected resources

The PKCE flow consists of these steps:

Challenge Generation: The client generates a random, cryptographically secure string called the code_verifier.
Hashing: The client hashes the code_verifier using SHA-256 to create the code_challenge.
Auth Request: The client sends the code_challenge and the hashing method to the Authorization Server.
Verification: When exchanging the authorization code, the client sends the plaintext code_verifier.
Token Issue: The Authorization Server hashes the verifier and compares it to the original challenge before issuing tokens.

OpenID Connect (OIDC): The Identity Layer on OAuth 2.0

Because OAuth 2.0 was designed strictly for authorization, developers began abusing it for authentication. They would use the presence of an access token to assume the user was authenticated. This created vulnerabilities because access tokens are meant for resource servers. They are not meant for clients and do not contain information about the authentication event itself. OpenID Connect (OIDC) was created in 2014 to resolve this. OIDC is a profile and extension built directly on top of OAuth 2.0. It adds authentication capabilities to the authorization framework.

How OIDC Extends OAuth 2.0

OIDC introduces three primary components:

The ID Token: A standardized JSON Web Token (JWT) that contains claims about the identity of the authenticated user.
Standardized Scopes: Predefined scopes like openid, profile, email, address, and phone that request specific user attributes.
The UserInfo Endpoint: A protected endpoint on the Authorization Server where the client can retrieve profile information using the access token.

Anatomy of an ID Token

The ID Token is always a JWT. It is composed of three parts separated by dots. These are the Header, the Payload, and the Signature. The Payload contains standard claims that the Relying Party can parse:

iss (Issuer): The identity of the authorization server that issued the token.
sub (Subject): A unique identifier for the user.
aud (Audience): The client ID of the application receiving the token.
exp (Expiration Time): The Unix timestamp when the token expires.
iat (Issued At): The Unix timestamp when the token was created.
auth_time (Authentication Time): The time the user actually logged in.

By validating the signature of the ID Token, the client verifies the user's identity. This uses the public keys published by the provider, allowing verification without additional API calls.

OIDC Discovery and Key Rotation

Clients use OIDC Discovery to dynamically configure themselves. They fetch metadata from the .well-known/openid-configuration endpoint. This JSON document contains the provider's authorization endpoint, token endpoint, and JSON Web Key Set (JWKS) URI. The JWKS contains the public keys used to verify the ID Token signatures. Using JWKS allows identity providers to rotate signing keys seamlessly without breaking client integrations.

How They Connect: Comparison and Interoperability

While SAML, OAuth 2.0, and OIDC are distinct, they often run side-by-side or connect within the same architecture.

Protocol Comparison

Dimension	SAML 2.0	OAuth 2.0	OpenID Connect (OIDC)
Primary Purpose	Enterprise Single Sign-On (SSO)	Delegated Authorization	Federated Authentication
Data Format	XML	JSON / Form URL Encoded	JSON (JSON Web Tokens)
Transport Protocol	SOAP / HTTP POST / Redirect	HTTP REST	HTTP REST
Token Type	SAML Assertion	Access / Refresh Token (Opaque or JWT)	ID Token (JWT) + Access Token
Client Type	Web Browser / Enterprise Apps	Web / Mobile / Single-Page / APIs	Web / Mobile / Single-Page / APIs
Security Mechanism	XML Signatures and Encryption	SSL/TLS + Cryptographic Signatures	SSL/TLS + JWT Signatures (JWS/JWE)

Real-World Bridging: SAML-to-OIDC

Modern enterprise architectures rarely use a single protocol. An enterprise might use a SAML-based identity provider internally. Examples of these providers include Active Directory Federation Services or Okta. However, their developers may want to build modern mobile and single-page applications using OIDC. In this case, an Identity Broker is deployed to act as a translator. The Identity Broker acts as an OIDC Provider to the client application. Simultaneously, it acts as a SAML Service Provider to the upstream identity source.

sequenceDiagram
    autonumber
    actor User as User Browser / Client App
    participant Broker as Identity Broker (OIDC Provider / SAML SP)
    participant SAML_IdP as Upstream SAML IdP
 
    User->>Broker: Initiate Login (OIDC Request)
    Broker->>User: Redirect with SAML Request (AuthnRequest)
    User->>SAML_IdP: Present AuthnRequest
    SAML_IdP->>User: Authenticate User
    SAML_IdP->>User: POST SAML Response (signed assertion)
    User->>Broker: Present SAML Response to ACS
    Broker->>Broker: Validate SAML Assertion
    Broker->>Broker: Map SAML attributes to OIDC claims
    Broker->>User: Redirect with Authorization Code
    User->>Broker: Exchange Auth Code for Tokens
    Broker->>User: Return OIDC ID Token & Access Token

This translation capability allows organizations to preserve their legacy enterprise identity infrastructure. At the same time, they can deliver modern, secure applications to end users.

Conclusion

Federated identity relies on choosing the right tool for the job. SAML remains dominant in traditional enterprise environments. These environments require robust, XML-based assertions and legacy SSO integrations. OAuth 2.0 provides the authorization framework necessary for securing API interactions and data sharing. OpenID Connect builds upon OAuth 2.0 to offer a lightweight, REST-friendly authentication layer for modern web and mobile applications. By understanding how these protocols relate and how they can be bridged, identity architects can build flexible systems that balance compatibility, performance, and security.

Love it? Share this article: