Oidc Validation

Prerequisites

• Target system, dependencies and environment configured.

Usage

Purpose

OpenID Connect adds authentication on top of OAuth2, and the ID token is its proof of who logged in. That proof only holds if the app validates the token properly — the wrong checks skipped, and an attacker forges or reuses an identity. This skill covers the ID-token validation an OIDC client must do, and the gaps that turn "log in with X" into account takeover.

When to use it

Any app that logs users in via OIDC — "Sign in with Google/Microsoft/Okta", or a custom identity provider. It complements the OAuth2 skill (which covers the flow) by focusing on what the client must verify about the token it gets back.

The checks an OIDC client must perform

Validate all of these on the ID token — skipping any one is a real weakness:

1. Signature — verify against the provider's published keys (JWKS). An unverified token is just attacker-supplied JSON. (The JWT-attacks skill covers alg-confusion/none here — pin the algorithm.)
2. iss (issuer) — must exactly match the expected identity provider. A token from a different issuer is not your IdP.
3. aud (audience) — must match your client ID. A token minted for another app/client must be rejected, even if signed by the same provider.
4. exp / iat — the token must be unexpired; reject stale tokens.
5. nonce — the value you sent in the auth request must come back in the token, tying it to this login and preventing replay/injection of a token from elsewhere.

Procedure

1. Capture the ID token returned after login (a JWT) and decode it.
2. Test signature enforcement — tamper with a claim, or try alg: none. If a modified/unsigned token is accepted, signature validation is broken (hand off to jwt-attacks).
3. Test aud enforcement — present a validly-signed token whose aud is a different client. If the app accepts it, an attacker can reuse a token obtained for another app to log in here. This is a frequently-missed, high-impact check.
4. Test iss enforcement — a token from an unexpected issuer should be rejected.
5. Test nonce handling — replay a token without the matching nonce, or reuse a prior token; it should fail.
6. Test expiry — replay an expired token; a valid-signature-but-expired token must be rejected.
7. Confirm the app derives identity from the validated token claims (sub), not from an untrusted field the client could influence.

Cheatsheet

ID token validation checklist (all required)
  [ ] signature verified against provider JWKS; algorithm pinned (no none)
  [ ] iss  == expected identity provider (exact)
  [ ] aud  == your client_id  (reject tokens minted for other clients!)
  [ ] exp  in the future; iat sane
  [ ] nonce matches the one sent in the auth request
  [ ] identity taken from validated `sub`, not a client-supplied field

high-value tests
  - token with aud = another client  -> accepted? (token reuse / takeover)
  - alg:none / tampered claim         -> accepted? (broken signature check)
  - expired token replayed            -> accepted? (no exp check)

Reading the output

• A token with a different aud accepted = token reuse across applications; an attacker who gets a token for any app using the same IdP logs in as that user here. High impact and commonly missed.
• A tampered or alg:none token accepted = broken signature validation; identities can be forged outright. Critical.
• Wrong iss accepted = the app trusts tokens from issuers it shouldn't.
• Missing nonce check = token replay/injection is possible; the login isn't bound to this session.
• Expired token accepted = stolen tokens have no time limit.
• All checks enforced = the client is validating correctly; note it as the good state.

The fix

• Use a certified OIDC library and enable full validation — don't hand-roll token parsing. The library validates signature, iss, aud, exp, and nonce when configured correctly; your job is to configure the expected issuer, audience, and JWKS.
• Pin the signing algorithm and fetch keys from the provider's JWKS endpoint (with rotation), never trust an alg from the token header.
• Always check aud against your client ID — this is the one teams skip, and it's what stops cross-app token reuse.
• Send and verify a nonce per login.
• Derive the user from sub (stable subject identifier) on the validated token, not from email or a mutable claim, and not from anything the client supplied.

Pitfalls

• Skipping the aud check. The classic OIDC bug — a signed token for another client sails through and logs the attacker in.
• Verifying signature but not claims. A perfectly signed token for the wrong audience/issuer, or expired, is still invalid here.
• Trusting the token header's alg. Opens alg-confusion/none. Pin it.
• Using email as the identity key. Emails change and can be spoofed across providers; use the immutable sub.

References

• OpenID Connect Core — ID Token Validation section
• OAuth 2.0 Security BCP (RFC 9700)
• OWASP JSON Web Token Cheat Sheet
• CWE-287, CWE-347

Inputs

• Relevant source code, logs, network traces, or system specifications.

Outputs

• Analysis findings, security audit report, or generated code artifacts.