Security
JWT pitfalls: 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 defense stick when you are reviewing real auth code.
Reconstruct the unit’s core mechanisms — algorithm pinning, key binding, claim checks, revocation, rotation, and storage tradeoffs — without looking back at the lesson.
- 01Walk through the RS256-to-HS256 algorithm-confusion attack and the two RFC 8725 defenses that stop it.
- 02A signature verifies correctly. Why is that necessary but not sufficient, and which claims must you still check?
- 03How can the kid (or jku/x5u) header turn into a key-injection vulnerability, and how do you neutralize it?
- 04Why does a stateless JWT have no real logout, and how do short TTLs plus refresh-token rotation contain a stolen token?
- 05Compare localStorage, httpOnly cookies, and in-memory storage for tokens. What attack does each invite and how do you mitigate?
- 06Why must an HMAC secret be at least 256 random bits from a CSPRNG, and what goes wrong with a human-chosen one?
If you could reconstruct each answer from memory, you hold the unit’s spine: pin the algorithm and bind each key to one algorithm so alg:none and RS256-to-HS256 confusion cannot fire; treat a valid signature as necessary but not sufficient and validate exp/nbf/iss/aud; resolve kid/jku only against a pinned allowlist so the header cannot inject a key; contain a stolen token with short access TTLs and refresh-token rotation with reuse detection since there is no instant logout; pick storage by which attack you would rather defend; and use a 256-bit CSPRNG secret so HMAC cannot be cracked offline.