5.2 Federated Access with OAuth2, SAML, and OpenID Connect

Federated access is how apps trust someone else's login

Knowledge area 2.1 also lists federated access, with Open Authorization 2 (OAuth2) and Security Assertion Markup Language (SAML) as the named examples. Federation means an application does not store the user's password. It trusts an identity provider (IdP) to authenticate the user and send a signed statement — a token or assertion — that the application, acting as a service provider (SP) or relying party (RP), can verify.

You implement federation when you join a Software as a Service (SaaS) application, when you let a mobile app call an application programming interface (API) on a user's behalf, and when two companies share an extranet without copying accounts. You maintain it when token-signing certificates expire, when redirect Uniform Resource Identifiers (URIs) drift, and when a former employee still has a live session at the SaaS.

The SSCP trap is treating OAuth2, OpenID Connect (OIDC), and SAML as synonyms. They are related, they are not the same protocol, and they fail in different ways.

Roles: identity provider versus service provider

The IdP holds the credentials and multi-factor authentication (MFA). The SP must not be given the directory password. If a vendor asks you to "sync passwords nightly," that is credential sharing, not federation. Federation is a signed statement plus a trust in the IdP's signing key.

OAuth2 is authorization and delegation

OAuth2 lets a user (resource owner) grant a client application limited access to a resource server without sharing a password. Classic picture: a calendaring app wants to read cloud mail. The user authenticates to the mail provider; the provider issues the calendaring app an access token scoped to mail.read, not to wipe the mailbox.

OAuth2 is not by itself an authentication protocol. It answers "what may this client do?" An access token is a capability — often a JSON Web Token (JWT) or an opaque handle. A refresh token lets the client obtain new access tokens without another interactive login. An authorization code is a short-lived code the client exchanges at the token endpoint. The authorization code flow with Proof Key for Code Exchange (PKCE) is the default for browser and mobile apps.

Grant types you will see on an operations shift:

• Authorization code: interactive user, browser redirect.
• Client credentials: daemon or service, no user — a machine identity.
• Refresh token: silent renewal of access tokens.
• Avoid or retire: implicit flow (tokens in the URL fragment) and resource-owner password credentials (the client sees the password).

Redirect URI registration is a hard control. The authorization server must send the code or token only to a pre-registered URI. If you allow a wildcard, or an open redirect such as https://app.example.com/callback?next=, an attacker can steal codes. Maintain the allowlist. Do not temporarily add http://localhost on a production app registration because a developer asked during a demo.

Scopes are least privilege for APIs. Mail.Read is not Directory.ReadWrite.All. An SSCP who rubber-stamps tenant-wide application permissions on a weekend integration has created a two-way trust with whoever later compromises that client secret.

OpenID Connect is the identity layer on OAuth2

OpenID Connect adds authentication on top of OAuth2. After the user signs in, the IdP issues an ID token — a signed JWT with identity claims (sub, iss, aud, exp, often email and groups). The RP validates signature, issuer, audience, and expiry, then treats the user as authenticated.

Contrast that with raw OAuth2: an access token that can call an API does not, by itself, tell a client who the user is in a way the client should trust for login. OIDC exists so SSO and "Sign in with ..." buttons have a standard identity artifact. SSCP items that say "identity layer on OAuth2" want OIDC, not SAML and not bare OAuth2.

OIDC still uses OAuth2's redirect, authorization code, and token endpoints. One flow can return both an ID token (who) and an access token (what). Do not confuse them. Presenting an ID token to an API that expected an access token, or stuffing extra privileges into an ID token, is a design smell. Validate nonce on the ID token to bind it to the browser session that started the login, and reject tokens whose aud is some other application.

SAML: XML assertions and enterprise SSO

SAML 2.0 is the enterprise SSO workhorse, especially for older and many SaaS products. The IdP produces a signed XML assertion that states the subject, authentication context, conditions (NotBefore, NotOnOrAfter, audience), and attributes (groups, employee number). The browser POSTs that assertion to the SP's Assertion Consumer Service (ACS) URL.

SAML is about authentication and attribute statements to an SP. It is not a general-purpose API authorization protocol. You typically use SAML to start a session; the SP then issues its own cookie. You do not staple a SAML assertion onto every Representational State Transfer call the way you send an OAuth2 bearer token.

Scenario: joining a SaaS application via SAML

A human-resources director buys a benefits SaaS. You, the SSCP practitioner, do not create a new password database. You:

1. Collect SP metadata: Entity ID, ACS URL, required NameID format (often email or a persistent opaque identifier), and which attributes the vendor actually needs.
2. Create a relying-party trust on ADFS, or an enterprise application on the cloud IdP. Upload the SP metadata. Return IdP metadata — Entity ID, SSO URL, token-signing certificate — to the vendor.
3. Map claims with least privilege: user.mail as NameID, department, groups. Do not send Social Security numbers in the assertion because a form field existed on the vendor's setup wizard.
4. Require MFA at the IdP. The SaaS should not become a second password prompt.
5. Pilot one user, then enforce. Document the ACS URL. A typo sends assertions into a void or, worse, toward a similar hostname an attacker registered.
6. Maintain the integration: signing-certificate rollover, leaver deprovisioning at the IdP (and System for Cross-domain Identity Management if the vendor supports it), and a vaulted break-glass local admin at the SaaS that is monitored — because when federation breaks, payroll still has to run.

That is federated access as an operations task, not a protocol religion. The diagram below is the happy path for that SAML join.

Tokens, assertion replay, and redirect traps

Assertion replay is the exam's favorite SAML failure. An attacker who captures a POST — compromised browser extension, leftover debug log, cleartext HTTP — resubmits the same assertion. If the SP does not check time windows, unique IDs, and audience, it opens a session for the attacker. The same idea applies to stolen authorization codes when redirect URIs are sloppy.

Validate, every time:

• Signature against the IdP's published signing key, not a key the attacker embedded in the message.
• Audience equals this SP, not any relying party in the metadata file.
• Time conditions, with a small clock-skew allowance. Network Time Protocol on both IdP and SP matters here.
• Destination / ACS matches the URL you configured.
• InResponseTo matches the request you sent, for SP-initiated flows.

Clock skew is an operations outage as well as a security control. If the SP is five minutes fast, valid assertions look expired. If it is five minutes slow, a just-expired assertion still works — which is a replay window.

Choosing SAML, OIDC, or OAuth2

Use SAML when the SaaS only speaks SAML — still the majority of "enterprise SSO" checkboxes. Use OIDC when you need modern SSO, mobile apps, and single-page logins. Use OAuth2 (often with OIDC in front for the user) when an application needs delegated access to an API. Do not say "we use OAuth2" when you meant "log the user in"; that is OIDC. Do not put SAML on a machine-to-machine daemon; that is client-credentials OAuth2.

Federation does not replace device authentication or phishing-resistant MFA at the IdP. It concentrates them there. That is why the IdP, the token-signing certificate, and the app-registration portal are crown-jewel systems: compromise one, and every connected SaaS session is in play. Maintain federation the same way you maintain any authentication method — inventory of apps, certificate lifetime, redirect-URI reviews, and a leaver process that kills IdP sessions instead of hoping each SaaS noticed.