6.2 Identity Federation: SAML 2.0, OpenID Connect, OAuth 2.0 & SCIM

6.2 Identity Federation: SAML 2.0, OpenID Connect, OAuth 2.0 & SCIM

Quick Answer: Identity Federation establishes a cryptographic circle of trust that allows users to authenticate once with a centralized Identity Provider (IdP) and securely access multiple disparate Service Providers (SPs) / Relying Parties (RPs) without replicating password databases. Modern cloud federation utilizes three core protocols: SAML 2.0 (heavyweight XML assertions for enterprise browser SSO), OAuth 2.0 (delegated authorization issuing scoped bearer tokens), and OpenID Connect (OIDC) (an identity layer atop OAuth 2.0 issuing lightweight JSON Web Tokens / JWTs). Because federation protocols authenticate users only on-demand during login, they leave a dangerous de-provisioning gap upon employee termination. To eliminate orphaned accounts and lingering sessions, enterprises mandate SCIM (System for Cross-domain Identity Management) for automated account provisioning and de-provisioning; separate application controls may be needed to revoke active sessions and local API tokens.

In the early era of distributed computing, every enterprise application maintained its own local database of usernames, password hashes, and user attributes. As organizations adopted dozens—and eventually hundreds—of Software as a Service (SaaS) and Infrastructure as a Service (IaaS) cloud offerings, this siloed model collapsed under insurmountable operational and security friction:

• Password Fatigue & Weak Credentials: Users forced to memorize dozens of distinct credentials defaulted to weak, reused passwords.
• Administrative Chaos: Onboarding and offboarding employees required IT teams to manually create or delete accounts across hundreds of isolated admin portals.
• Orphan Account Vulnerabilities: When employees departed the company, administrators inevitably forgot to disable access in obscure third-party cloud tools, leaving active credentials exposed to rogue ex-employees or external threat actors.

To resolve these vulnerabilities, modern cloud architecture mandates Identity Federation.

---

Federation Architecture: The Cryptographic Circle of Trust

Identity Federation decouples authentication from service consumption. Instead of each cloud application verifying credentials directly, the application delegates authentication to an authoritative, centralized identity engine.

┌────────────────────────────────────────────────────────────────────────┐
│                     FEDERATION CIRCLE OF TRUST                         │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│   ┌───────────────────────────┐         ┌──────────────────────────┐   │
│   │   Identity Provider (IdP) │         │  Service Provider (SP) / │   │
│   │   (Authoritative Store)   │         │   Relying Party (RP)     │   │
│   │                           │         │   (Cloud App / SaaS)     │   │
│   │  • Authenticates Users    │         │  • Delivers Service      │   │
│   │  • Enforces MFA           │         │  • Enforces Local AuthZ  │   │
│   │  • Issues Signed Assertions│        │  • Trusts IdP Signature  │   │
│   └─────────────┬─────────────┘         └────────────▲─────────────┘   │
│                 │                                    │                 │
│                 │  Trust Established Out-of-Band:    │                 │
│                 │  • Public Key / X.509 Certificate  │                 │
│                 │  • Entity ID / Issuer URI          │                 │
│                 │  • Redirect Endpoints (ACS URL)    │                 │
│                 └────────────────────────────────────┘                 │
│                                                                        │
└────────────────────────────────────────────────────────────────────────┘

Core Architectural Roles

1. Identity Provider (IdP): The authoritative identity entity that stores user credentials (or connects to an enterprise directory like Active Directory or LDAP), performs authentication, enforces MFA policies, and generates cryptographically signed identity assertions. Examples include Microsoft Entra ID, Okta, Ping Identity, and Google Workspace.
2. Service Provider (SP) / Relying Party (RP): The workload, cloud service, or application providing value to the end user. Under SAML terminology, this entity is designated the Service Provider (SP); under OpenID Connect and OAuth terminology, it is designated the Relying Party (RP). The SP/RP does not collect or store user passwords; it trusts the identity assertions issued by the IdP.
3. User Agent: Typically a modern web browser or mobile client acting on behalf of the user to traverse redirects and submit tokens between the IdP and the SP.

The Cryptographic Trust Relationship

Federation does not imply unverified transmission of identity claims. The trust relationship is anchored in asymmetric public-key cryptography:

• The IdP possesses a private key used to sign assertion tokens.
• The SP imports the IdP's public key (often packaged inside an X.509 digital certificate via SAML metadata XML or an OIDC JSON Web Key Set [JWKS] endpoint).
• When the SP receives a token, it validates the cryptographic digital signature against the trusted public key, verifies that the timestamp has not expired (NotOnOrAfter), and confirms that the token was explicitly addressed to its own client identifier (Audience). If any check fails, access is rejected.

---

SAML 2.0 (Security Assertion Markup Language)

Standardized by OASIS in 2005, SAML 2.0 is an XML-based framework specifically engineered for cross-domain Web Browser Single Sign-On (SSO). It remains the dominant federation standard across traditional enterprise SaaS platforms.

Anatomy of a SAML Assertion

A SAML Assertion is an XML document packaged with cryptographically verifiable elements:

• Issuer: The unique URI identifying the IdP.
• Subject: The authenticated entity, typically represented as a NameID (e.g., user@enterprise.com).
• Conditions: Constraints defining validity, including NotBefore and NotOnOrAfter timestamps, and the designated AudienceRestriction.
• AuthnStatement: Details regarding the authentication event, including the exact timestamp, authentication context class (indicating whether password, MFA, or smartcard was used), and session index.
• AttributeStatement: Key-value pairs transmitting user metadata (e.g., Email, FirstName, Department, EmployeeID, Role).
• XMLDSig (XML Digital Signature): Cryptographic signature ensuring message integrity and non-repudiation.

SP-Initiated vs. IdP-Initiated SSO

• SP-Initiated Flow (Recommended): The user navigates directly to the cloud application (e.g., https://crm.cloudservice.com). The SP detects an unauthenticated session, generates an encoded SAMLRequest (AuthnRequest), and redirects the user's browser to the IdP. After the user authenticates, the IdP sends a signed SAMLResponse back to the SP's Assertion Consumer Service (ACS) URL via an HTTP POST.
• IdP-Initiated Flow: The user logs into their corporate portal (e.g., https://myapps.enterprise.com) and clicks an application tile. The IdP generates an unsolicited SAMLResponse and posts it directly to the SP's ACS endpoint.

[!WARNING] IdP-Initiated Security Risk: IdP-initiated SAML SSO is inherently vulnerable to Cross-Site Request Forgery (CSRF) and credential replay attacks because the SP receives an unsolicited assertion without having initiated a request containing a cryptographic state/nonce. CSA recommends enforcing SP-initiated flows wherever feasible.

---

OAuth 2.0: Delegated Authorization Framework (RFC 6749)

A pervasive misconception on cloud security examinations is treating OAuth 2.0 as an authentication protocol. OAuth 2.0 is strictly a framework for delegated authorization.

The Problem OAuth Resolves

Prior to OAuth, if a user wanted a third-party print service to access their photos stored in a cloud drive, the user had to give their raw cloud drive username and password to the print service. This anti-pattern had catastrophic security implications: the print service had unlimited access to all files, credentials were stored insecurely by third parties, and revoking access required changing the primary account password.

OAuth 2.0 solves this by introducing token-based authorization delegation. The user authorizes the application to access specific resources on their behalf, without ever revealing their credentials to the application.

The Four OAuth Roles

1. Resource Owner: The entity capable of granting access to a protected resource (typically the human end user).
2. Client: The third-party application requesting access to the resource (e.g., a mobile app, web app, or automated background service).
3. Authorization Server: The server that authenticates the Resource Owner and issues scoped tokens to the Client after obtaining authorization.
4. Resource Server: The server hosting the protected resources (e.g., a cloud REST API), capable of accepting and validating Access Tokens.

OAuth Token Architecture: Access Tokens, Refresh Tokens, and Scopes

• Access Token: An opaque string or signed JSON Web Token (JWT) representing authorization. It is presented as a Bearer Token in the HTTP Authorization: Bearer <token> header to access protected APIs. Access tokens are engineered with very short lifespans (e.g., 15 to 60 minutes) to minimize the blast radius of token theft.
• Refresh Token: A long-lived credential issued alongside the access token. When the access token expires, the client submits the refresh token directly to the Authorization Server to obtain a fresh access token without prompting the user to re-authenticate. Refresh tokens are subject to strict replay detection and one-time-use rotation.
• Scopes: Granular permission strings that delimit what the client application is authorized to do (e.g., scope=openid profile email files.read).

OAuth Grant Types (Flows)

Proof Key for Code Exchange (PKCE - RFC 7636)

In native mobile applications and browser-based SPAs (known as Public Clients), the client cannot securely store a private client_secret because client-side binary code or JavaScript can be decompiled. To prevent malicious software from intercepting authorization codes transmitted via custom URI schemes:

1. The client creates a cryptographically random secret called a Code Verifier and computes its SHA-256 hash, termed the Code Challenge.
2. The client transmits the Code Challenge in the initial authorization request.
3. When exchanging the authorization code for tokens, the client sends the raw Code Verifier.
4. The Authorization Server hashes the verifier and compares it against the original challenge. Only the entity that created the original challenge can complete the exchange, completely neutralizing code interception attacks.

---

OpenID Connect (OIDC): Modern Identity Layer

While OAuth 2.0 delivers delegated authorization, developers frequently attempted "pseudo-authentication" by assuming that possession of an OAuth access token proved user identity. Because access tokens do not contain audience bindings, issue timestamps for identity verification, or user metadata intended for the client, this practice caused widespread authentication bypasses.

To standardize identity authentication over OAuth 2.0, the OpenID Foundation developed OpenID Connect (OIDC).

$\text{OpenID Connect (OIDC)} = \text{OAuth 2.0 (Authorization Framework)} + \text{Identity Layer (AuthN / JWT)}$

The JSON Web Token (JWT - RFC 7519)

OIDC transmits identity claims using compact, URL-safe JSON Web Tokens (JWTs). A JWT is structurally composed of three distinct Base64URL-encoded JSON objects separated by dots (.):

$\text{JWT} = \underbrace{\text{Header}}_{\text{Algorithm \& Key ID}} \; . \; \underbrace{\text{Payload}}_{\text{Identity Claims}} \; . \; \underbrace{\text{Signature}}_{\text{Cryptographic Proof}}$

// 1. Header
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "k-2026-auth-prod-01"
}

// 2. Payload
{
  "iss": "https://identity.enterprise.com",
  "sub": "usr_88392104",
  "aud": "cloud-crm-app",
  "exp": 1790294400,
  "iat": 1790290800,
  "auth_time": 1790290790,
  "nonce": "n-0S6_WzA2",
  "email": "alex.chen@enterprise.com",
  "department": "Infrastructure Security"
}

// 3. Signature
RSASHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  privateKey
)

The Core Distinction: ID Token vs. Access Token

• ID Token (id_token): A signed JWT issued exclusively for the client application. It contains verifiable assertions about the authentication event (iss, sub, aud, exp, auth_time, nonce). The client application validates the signature and reads the claims to log the user in and render their profile.
• Access Token (access_token): A credential issued for the Resource Server (API). The client application never inspects the access token; it simply attaches it as a bearer token to API requests.

---

Protocol Comparison: SAML 2.0 vs. OAuth 2.0 vs. OpenID Connect

---

Automated Identity Lifecycle Management: SCIM (RFC 7643 & RFC 7644)

A critical vulnerability in cloud IAM deployments arises from assuming that deploying SAML or OIDC solves user account governance. It does not. Federation protocols operate strictly just-in-time at the moment of login.

The "De-Provisioning Gap" in Pure SSO

Consider what occurs when an enterprise uses SAML SSO across 50 third-party SaaS tools without automated provisioning:

1. An employee logs into a SaaS tool for the first time. The SaaS tool inspects the SAML assertion and creates a local user account—a process called Just-In-Time (JIT) Provisioning.
2. Six months later, the employee is terminated. HR deactivates the user in the corporate Active Directory / IdP.
3. The user can no longer log in via Web SSO. However:
   • The user's account, personal files, and shared links still exist inside the 50 SaaS applications.
   • If the user had active sessions on native mobile apps or generated long-lived personal API tokens within those SaaS tools, those sessions and tokens remain active and functional, bypassing the IdP entirely.
   • The enterprise continues paying monthly licensing fees for hundreds of orphaned accounts.

HR Terminates User ──► User Disabled in Central IdP
                             │
       ┌─────────────────────┴─────────────────────┐
       ▼                                           ▼
[Without SCIM (The Gap)]                [With SCIM Automation]
 • SAML SSO blocked                      • IdP sends real-time HTTP PATCH/DELETE
 • Active SaaS sessions may persist      • Downstream SaaS account disabled
 • Local API tokens may still work        • Separate session/token revocation invoked
 • Data access through orphan accounts    • Access state verified
 • Ongoing license fee waste             • Licenses reclaimed automatically

The SCIM Solution (RFC 7643 & RFC 7644)

The System for Cross-domain Identity Management (SCIM) standard eliminates this vulnerability by defining a standardized, RESTful JSON protocol for managing user identities across cloud platforms.

• RFC 7643: Defines the core schema, resource types (/Users, /Groups), and standardized attribute mappings (e.g., userName, name.givenName, emails, active, roles).
• RFC 7644: Defines the HTTP protocol operations. The central IdP acts as a SCIM Client, calling SCIM REST endpoints hosted by the cloud SaaS application (the SCIM Service Provider):
  • POST /Users — Automatically creates the user account before they ever log in.
  • PUT / PATCH /Users/{id} — Updates department, manager, or role attributes in real time when an employee transfers.
  • PATCH /Users/{id} {"Operations": [{"op": "replace", "path": "active", "value": false}]} — Disables the downstream account through the SCIM service. Revocation of existing sessions or application-issued API tokens depends on the service and may require separate APIs or orchestration.
  • DELETE /Users/{id} — Removes the user account or archives data according to data retention policies.