Lesson 1.24: Validating JSON Web Tokens
APIs usually accept a JSON Web Token (JWT) instead of a session cookie: three base64url parts, a header, a payload with claims such as subject, audience and expiry, and a signature. A JWT is only as trustworthy as the checks the server makes. Accepting the algorithm 'none', skipping the audience, or tolerating an hour of clock skew turns a token into a self-written pass. In the lab you decode Northwind's tokens by hand, verify an HS256 signature with openssl, take apart a forged token an attacker used against the admin API, and fix the validation settings.
17 min
You will learn to
- Explain the structure of a JWT
- Decode base64url parts
- Verify an HS256 signature
- Recognise the alg 'none' attack
- Configure strict validation: algorithms, issuer, audience, expiry
Key terms
- JWT
- A compact token: base64url(header).base64url(payload).signature (RFC 7519).
- Claims
- Statements in the payload: iss, sub, aud, exp, iat, plus custom ones like role.
- HS256 / RS256
- HMAC-SHA256 with a shared secret / RSA signature with a private key that only the issuer holds.
- alg 'none'
- An 'unsecured' JWT with no signature; servers must never accept it for authentication.
- base64url
- base64 with - and _ instead of + and /, usually without = padding.
- Clock skew
- Tolerance for clocks that differ between servers when checking exp and nbf.
← Anatomy of a web application · All lessons · Privileged groups and nested membership →