OpenID Connect ID Token Validation Lab (Interactive)
Replay, re-audience, and tamper with ID tokens while you hold the validation checklist. Distinguish identity from delegation: validate iss, aud, exp, nonce, and at_hash claims against discovery-doc keys and watch which missing check lets each attack land.
OIDC ID Token Validation Gate
Enable or skip client-side checks while attacks arrive, and decide whether this token proves identity (AuthN) or grants API access (AuthZ).
Incoming ID token
iss: https://accounts.google.com
sub: 109823491823901238
aud: my-spa-client-889
exp: 1714003600
nonce: n-OLD_STOLEN_7x
at_hash: f9m_28v1Lq08_Xz9Q
email: alice@example.com
name: Alice Smith
OIDC = OAuth 2.0 + scope=openid + a signed ID token, discovered automatically via /.well-known/openid-configuration. The nonce echoed by the IdP proves the token belongs to this login attempt, defeating replay; auth_time lets you force re-auth on stale sessions.
How It Works Under the Hood
OAuth 2.0 delegates access; OpenID Connect adds identity by handing the client a signed ID token, a JWT asserting who authenticated at the authorization server. Two tokens, two audiences: the access token is for the API, the ID token is strictly for the client, and confusing them creates the confused-deputy problem. Every security property lives in the validation checklist: signature against the provider's JWKS, issuer matching the discovery document, audience matching your client id, expiry bounds, and nonce equality against the authentication request to defeat replay. The lab presents each attack alongside toggles for each check, so a passing token is only as trustworthy as the strictest rule you enforced.
Core Architectural Principles
- Replay attack succeeds unless the nonce claim is compared with the value bound to this client session.
- Wrong-audience tokens (from another client) pass signature checks; only aud validation rejects them.
- Sending an ID token as a bearer access token misuses identity credentials at the API.
Open by separating OAuth (delegation) from OIDC (identity on top of OAuth), then rattle off the validation checklist: signature, iss, aud equals client id, exp and iat bounds, and nonce for flows with a browser. Mention discovery at the well-known openid-configuration path and at_hash binding, and interviewers know you have actually shipped it.
OIDC buys standardized federated identity but pushes correctness onto exhaustive claim validation the client cannot skip.