Last updated: April 29, 2026
Authentication and authorization are where most API security work lives. Get them right and the rest of your defenses operate from a solid foundation. Get them wrong and every endpoint is potentially compromised. This module covers JWT pitfalls, OAuth 2.0 flows for APIs, session management patterns, and the things to test in each.
JWT — the pitfalls
JSON Web Tokens are everywhere. They are also full of footguns:
- “none” algorithm bypass: some libraries accept
{"alg":"none"}and skip signature verification. Older bug; still appears in custom verifiers - Algorithm confusion (RS256 vs HS256): server expects RS256 (asymmetric); attacker submits HS256 token signed with the public key (which they obtained legitimately). HS256 verifier uses the public key as HMAC secret → signature passes
- Weak HMAC secret: JWT signed with
secret123; offline crack via hashcat in seconds - kid injection: kid header pointing to attacker-controlled key
- jku/x5u abuse: JWT claims a key URL; some verifiers fetch and trust it
- Expiration not enforced: token from last year still works
- Token reuse after logout: JWT is stateless; without revocation infrastructure, “logout” just means client deletes token
- Secrets in JWT body: JWT base64-encodes — does not encrypt. Anything in the body is readable
JWT testing checklist
# Test 1: alg=none
echo -n '{"alg":"none","typ":"JWT"}' | base64 -w0
echo -n '{"sub":"admin"}' | base64 -w0
# Final token: HEADER.PAYLOAD. (note trailing dot, empty signature)
# Test 2: HS256 confusion using known RS256 public key
# (Use jwt_tool by ticarpi)
jwt_tool TOKEN -X k -pk public.pem
# Test 3: Crack weak HS256 secret offline
hashcat -a 0 -m 16500 token.txt rockyou.txt
# Test 4: Replay expired token; verify rejection
# Test 5: Decode body — any sensitive fields you can see?
Custom team training + practitioner advisory
Beyond the free academy — we run private workshops, vCISO advisory, and red-team exercises tailored to your stack. For Indian SMBs scaling past their first hire.