Federated Identity: SAML, OAuth, and OpenID Connect

In modern enterprises, employees need to access dozens of applications — cloud apps, SaaS tools, partner portals, and internal systems — each potentially maintained by different organizations. Creating and managing separate accounts for each is insecure (credential proliferation) and inefficient. Federated identity solves this by allowing an Identity Provider (IdP) — a trusted, authoritative source of identity — to authenticate users and share that authenticated identity with Service Providers (SPs) across organizational boundaries. Users authenticate once and gain access to multiple systems without re-entering credentials.

Single Sign-On (SSO) allows users to authenticate once and access multiple applications within a session without re-authenticating. The user logs in to the Identity Provider (corporate Active Directory, Okta, Azure AD), receives a session token or assertion, and presents this token to each Service Provider they visit. SSO improves security by reducing the number of passwords users must manage (reducing reuse), enabling centralized authentication policy enforcement, and allowing immediate access revocation across all integrated applications when an account is disabled at the IdP level.

SAML (Security Assertion Markup Language) 2.0 is the XML-based open standard for exchanging authentication and authorization data between Identity Providers and Service Providers. The SAML flow: (1) user accesses a Service Provider (e.g., Salesforce), (2) SP redirects to the Identity Provider (e.g., Okta), (3) user authenticates at the IdP, (4) IdP issues a signed XML SAML Assertion containing the user's identity and attributes, (5) the assertion is returned to the SP, (6) SP validates the assertion's signature using the IdP's public key and grants access. SAML is widely used for enterprise SSO in web applications.

Three parties participate in a SAML federation. The Principal is the user (or system) seeking access — they initiate the authentication process. The Identity Provider (IdP) is the authoritative source of identity that authenticates the principal and issues assertions — examples include Microsoft Azure AD, Okta, Ping Identity, and ADFS. The Service Provider (SP) consumes the assertion and grants access based on it — examples include Salesforce, Google Workspace, AWS, and any SAML-enabled application. The SP and IdP establish trust in advance by exchanging metadata containing each other's endpoint URLs and signing certificates.

OAuth 2.0 is an authorization framework (not an authentication protocol) that allows a third-party application to access resources on behalf of a user without exposing the user's credentials. The classic use case: 'Allow this photo editing app to access your Google Photos.' OAuth 2.0 introduces four roles: the Resource Owner (user), the Client (third-party app), the Authorization Server (issues tokens), and the Resource Server (hosts the protected resource). The user authorizes the client, which receives an access token it presents to the resource server — never needing the user's actual password.

The Authorization Code Flow is the most secure OAuth 2.0 flow for web applications. The flow: (1) Client redirects user to the Authorization Server with requested scopes; (2) User authenticates and grants consent at the Authorization Server; (3) Authorization Server redirects back with a short-lived authorization code; (4) Client exchanges the code for an access token (and optionally a refresh token) via a server-to-server call with client credentials; (5) Client uses access token to call the Resource Server. The code exchange happens server-side, preventing the access token from being exposed in browser history or logs.

OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0. OAuth only provides authorization (access tokens proving what the client can do); OIDC adds authentication (an ID token proving who the user is). OIDC adds an openid scope to the OAuth flow and returns a signed JWT (JSON Web Token) ID Token alongside the access token. The ID token contains claims (name, email, sub [subject identifier]) that identify the user. OIDC is now the dominant protocol for consumer-facing SSO — 'Sign in with Google/Apple/Microsoft' buttons all use OIDC.

JSON Web Tokens (JWT) are a compact, URL-safe format for representing claims between parties. A JWT has three base64url-encoded parts separated by dots: Header (algorithm and token type), Payload (claims: iss, sub, aud, exp, iat, and custom claims), and Signature (cryptographic signature verifying the token's integrity). JWTs are self-contained — the Resource Server can verify them without calling back to the Authorization Server, improving performance and enabling stateless architectures. The critical security requirement: always verify the JWT signature and check the exp (expiry) and aud (audience) claims.

Understanding when each standard applies is critical for the Security+ exam. SAML 2.0: enterprise SSO for web applications, browser-based flows, XML assertions. Legacy but widely deployed in enterprise. OAuth 2.0: API authorization — granting third-party apps limited access to resources. Does not authenticate users directly. OIDC: consumer and modern enterprise authentication (SSO), built on OAuth 2.0. Returns JWT ID tokens identifying the user. In practice: enterprise environments often use SAML for application SSO and OIDC for API/mobile authentication. Modern cloud-native environments prefer OIDC over SAML for its JSON/JWT format and better mobile support.

Federated identity systems introduce specific attack vectors. Assertion replay attacks: an attacker intercepts a SAML assertion and replays it to gain access. Mitigated by short assertion lifetimes and one-time-use assertion IDs. XML signature wrapping (XSW): in SAML, attackers can sometimes manipulate signed XML to alter claims while keeping the signature valid on the original content. JWT algorithm confusion: if a server accepts both RS256 (asymmetric) and HS256 (symmetric) algorithms, an attacker can forge JWTs by using the server's public key as the HMAC secret for HS256. Always validate algorithm header matches expected algorithm. Open redirectors: OAuth redirect URIs must be exactly matched to prevent token theft via redirection to attacker-controlled sites.

Enterprise identity federation often requires synchronizing user identity data between systems. SCIM (System for Cross-domain Identity Management) is a REST API standard for automating user provisioning and deprovisioning between an Identity Provider and connected Service Providers. When a new employee is added to Azure AD (IdP), SCIM automatically creates their account in Salesforce, Slack, GitHub, and other SCIM-compatible apps. When the employee is terminated, SCIM deactivates all accounts simultaneously — closing the window where orphaned accounts could be exploited. SCIM complements SSO protocols (SAML/OIDC) by handling the lifecycle management that SSO protocols don't address.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: SAML 2.0 uses XML assertions for enterprise browser-based SSO; OAuth 2.0 is an authorization framework for API access delegation; OpenID Connect adds authentication (JWT ID tokens) on top of OAuth; and SCIM automates identity lifecycle management across federated systems. This completes the Authentication and Authorization course — next we explore Network Security Fundamentals.