OAuth / SAML / SSO

Federated login (“Sign in with Google/Microsoft”) delegates authentication to an identity provider (IdP). Flaws usually aren’t in the protocol but in how the app implements it: lax validations that let an attacker steal the victim’s code/token and take over their account.

sequenceDiagram
    participant U as User
    participant C as Client (app)
    participant AS as Authorization server
    U->>C: sign in with the provider
    C-->>U: redirect to AS (client_id, redirect_uri, scope)
    U->>AS: authenticates and consents
    AS-->>U: redirect to redirect_uri with code
    U->>C: delivers the code
    C->>AS: exchanges code for token (client_secret)
    AS-->>C: access_token

Threat model

Account takeover (ATO) of the user in the client app, access-token theft, and access to whatever the scope grants (email, profile, APIs).

Anatomy

OAuth 2.0 (authorization) defines roles: resource owner (user), client (the app), authorization server (IdP). The recommended flow is authorization code + PKCE; implicit is deprecated. Key parameters: redirect_uri, state, scope, code. OIDC adds authentication with an id_token (JWT). SAML does the equivalent with signed XML assertions.

Red Team

OAuth/OIDC attacks

Weak redirect_uri: if validation isn’t exact (allows subdomains, paths, an open redirect), redirect the code/token to your domain → code theft.
Missing/unvalidated state: login CSRF → force the victim to sign in with your account, or link their account to yours.
code leakage: via Referer, in logs, or through a chained open redirect.
Implicit flow: token travels in the fragment → easier leakage.
Account linking / pre-ATO: register the victim’s account before they use SSO.
SSRF via manipulable discovery/jwks_uri; JWT confusion in the id_token (see the JWT page).

SAML attacks

Signature not validated or validated poorly → accept forged assertions.
XML Signature Wrapping (XSW): restructure the XML so one part is validated and another is processed.
Comment/NameID injection and XXE in the SAML parser.

Tooling

Burp Suite (+EsPReSSO), SAML Raider (manipulate/sign assertions), and your own server to capture codes/tokens.

Impact and chaining

Direct ATO, API access with the stolen token, and pivoting to everything SSO protects.

Blue Team

Detection

Authorization requests with redirect_uri outside the registered list.
Missing state/PKCE; id_token with wrong iss/aud/nonce.
SAML assertions with invalid signatures or anomalous structure (XSW).

Telemetry and sources

IdP and OAuth-client logs, WAF, and token/assertion validation.

Hardening

Exact-match redirect_uri (full allow-list, no wildcards).
Mandatory state + PKCE on all flows; use authorization code, not implicit.
Validate iss, aud, nonce, exp of the id_token; fixed, trusted jwks_uri.
SAML: validate the signature strictly (schema + canonicalization), disable DTD (anti-XXE), and defend against XSW with robust libraries.

Response

Invalidate sessions/tokens, fix validations, and review suspicious account linkings.

CVEs and real-world cases

XML Signature Wrapping in SAML — a flaw class that affected multiple enterprise SSO products and SDKs over the years.
“Sign in with…” misconfigurations — lax redirect_uri/state have led to numerous ATOs reported in bug bounty.

Product-specific CVEs in NVD (https://nvd.nist.gov/vuln/search) and GitHub Advisories (https://github.com/advisories).

Testing checklist

redirect_uri validation (subdomain, path, chained open redirect).
state present and validated; PKCE in use.
code/token leakage via Referer/logs/fragment.
id_token: iss/aud/nonce/signature (see JWT).
SAML: signature, XSW, XXE in the parser.