OAuth 2.0, SAML and SSO

What it is

Identity federation lets a user authenticate once with an identity provider (IdP) and reuse that identity across many applications — single sign-on (SSO). OAuth 2.0 delegates authorization; OpenID Connect (OIDC) layers authentication on top; SAML exchanges signed XML assertions typically in enterprise web SSO.

Why it matters

Federation concentrates trust: one IdP, many relying parties. A misconfiguration (welcome it without validating the assertion, trusting a spoofable audience, or a stolen token) compromises every connected application. These are frequent root causes of real breaches.

How it works

• OAuth 2.0: resource owner grants a client an authorization code/token to act on its behalf. PKCE binds the code-exchange to a verified client to stop interception.
• OIDC: returns an ID Token (JWT, see guides:decode-jwt-safely) proving the user’s identity. Relying parties must validate issuer, audience, signature and expiry.
• SAML 2.0: IdP sends a signed XML assertion to the SP. Must verify signature, validate the AudienceRestriction and NotOnOrAfter conditions.

Detection

• SSO tokens/assertions accepted from an unexpected issuer or audience.
• Authorization-code interception patterns (missing PKCE, token in URL).
• A spiked number of first-time SSO logins for one principal (token replay).

Mitigation

• Always use PKCE for public clients; validate issuer, audience, signature and expiry on every token/assertion.
• Prefer short-lived scoped tokens; rotate secrets; do not log tokens or assertions.
• Centralize MFA enforcement at the IdP (see security:identity-mfa).

Investigation

Capture the token/assertion metadata (issuer, audience, expiry, signing key) and the SP’s validation logs to determine whether an unsigned/unvalidated assertion was accepted. See guides:tool-jwt-guide for decoding and inspecting a JWT safely.