Security
OAuth/OIDC: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the mechanism stick. These are the explanations you would give in a design review.
Reconstruct the unit’s core mechanisms — PKCE binding, exact redirect matching, the id_token checks, JWKS rotation handling, refresh rotation, and sender-constrained tokens — without looking back at the lessons.
- 01What does PKCE prevent, and exactly how does the binding work end to end?
- 02Why does OAuth 2.1 require exact-match redirect URIs, and what attack does prefix matching enable?
- 03List the mandatory id_token checks and name the attack each one blocks.
- 04Explain JWKS cache staleness during key rotation and the on-cache-miss refresh pattern.
- 05How does refresh-token rotation turn a stolen refresh token from unlimited harm into a detection window?
- 06What makes a DPoP-bound token resist theft, and when would you choose mTLS instead?
If you could reconstruct each answer from memory, you hold the unit’s spine: PKCE binds the code to its client, exact redirect matching keeps the code on-domain, the id_token checks (with a pinned algorithm) authenticate the user, on-cache-miss JWKS refresh survives key rotation, refresh rotation converts theft into a replay alarm, and DPoP or mTLS makes a stolen token unusable. OAuth security is a complete-set problem — every check, every time.