Security
OAuth/OIDC: multiple-choice review
Crux Multiple-choice synthesis across the OAuth/OIDC unit — PKCE, exact redirect match, id_token checks, refresh rotation, sender-constrained tokens, and audience attacks.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a decision in a real incident or design review — not a definition to recite, but a mandatory check to defend. The unit’s thesis: skip any one and you ship a CVE.
Goal
Confirm you can connect PKCE, exact redirect matching, the eight id_token checks, refresh rotation, sender-constrained tokens, and audience validation into one complete-set security model.
Quiz
Completed
Your OAuth client is a confidential server-side app with a client_secret. A reviewer asks why you still send PKCE. What is the correct answer?
Heads-up PKCE is in addition to the client_secret for confidential clients, not a replacement. Both run together.
Heads-up OAuth 2.1 mandates PKCE for ALL clients, including confidential ones, precisely so a leaked secret alone cannot redeem an intercepted code.
Heads-up PKCE adds roughly 50 bytes per request and a hash check; it is a security control, not a size or speed optimization.
Quiz
Completed
A team registers redirect_uri as a prefix match (https://app.example/callback*) to support dynamic return paths. Why is this a vulnerability?
Heads-up The host is not enough. An open redirect on a permitted path under that host forwards the code off-domain; only character-for-character exact match closes this.
Heads-up PKCE binds the code to the verifier, not to the path. The redirect-URI rule is an independent mandatory check that prefix matching defeats.
Heads-up Exact match is required for all clients. Native apps additionally use loopback or registered private-use schemes, but web apps must exact-match too.
Quiz
Completed
An OIDC client validates the id_token signature, iss, exp, and nonce — but reads the algorithm to use from the token's own alg header. What is the flaw?
Heads-up The alg header is attacker-controlled input. The validator must pin the expected algorithm from configuration and ignore the token's claim.
Heads-up aud is indeed mandatory, but trusting alg is independently exploitable via alg=none and RS256-to-HS256 confusion.
Heads-up Algorithm confusion applies to any JWT you verify, including the id_token. The signature check is only as strong as the pinned algorithm.
Quiz
Completed
A refresh token leaks through an access log. Refresh-token rotation is enabled. What is the maximum window of harm?
Heads-up Rotation marks the old token used on every refresh, so the absolute-expiry window no longer applies — replay detection ends it far sooner.
Heads-up Refresh tokens are revocable, and rotation automates detection: the replay collapses the whole chain on the next legitimate use.
Heads-up There is no fixed five-minute rule. The window depends on when the legitimate client next refreshes and triggers replay detection.
Quiz
Completed
A supply-chain attack injects JavaScript into your SPA and exfiltrates the access token from memory. The token is bound with DPoP. Why does the stolen token fail at the resource server?
Heads-up DPoP does not bind to IP. It binds to a client-held private key via the proof signature and the cnf.jkt thumbprint check.
Heads-up DPoP does not encrypt the token; the token can be stolen. It binds USE of the token to possession of a private key the attacker lacks.
Heads-up Short TTL only bounds a bearer token's window. DPoP is what makes the stolen token unusable immediately, even within its TTL.
Quiz
Completed
One authorization server issues tokens for API-A and API-B. API-B's validator runs: if token.aud contains any known client_id, accept. Why is this an audience-confusion vulnerability?
Heads-up client_id identifies the client, not the resource server. The defect is validating aud against a membership set instead of a hard-coded expected audience.
Heads-up Expiry is unrelated. A live token for API-A passes API-B's broken check and grants cross-API access for its full TTL.
Heads-up Introspection reports revocation and activity but does not replace audience validation — you still must verify aud equals this server's identifier.
Recap
The through-line across the unit is one complete-set rule: PKCE binds the code to the client, exact redirect matching keeps the code on-domain, the eight id_token checks (with a server-pinned algorithm) authenticate the user, refresh rotation turns theft into a detection alarm, sender-constrained tokens (DPoP/mTLS) defeat bearer theft, and audience validation against a hard-coded identifier blocks cross-API confusion. Every real OAuth breach — Facebook, Slack, GitHub Enterprise, Azure AD — traces back to exactly one of these checks being skipped or inverted.