Anatomy of a JSON Web Token
A JSON Web Token looks like three random-looking strings joined by dots. Each segment is Base64URL-encoded and decodes to reveal header, payload, and signature.
1. The Three Parts of a JWT
Every JWT is three Base64URL-encoded segments separated by dots: header.payload.signature. Decoding reveals:
- Header — metadata:
{"alg":"HS256","typ":"JWT"}. Thealgfield tells the verifier which algorithm to use. - Payload — the claims, which are JSON key/value pairs describing the subject and context of the token.
- Signature — computed as
HMAC-SHA256(base64url(header) +"." + base64url(payload), secret)for HS256.
2. Standard Registered Claims
The JWT specification defines seven registered claims. Custom claims are also allowed and typically identify application-specific data.
- iss (Issuer) — The principal that issued the token
- sub (Subject) — The user or entity the token represents
- aud (Audience) — The intended recipient
- exp (Expiration time) — Unix timestamp after which the token must be rejected
- nbf (Not before) — Unix timestamp before which the token must be rejected
- iat (Issued at) — Unix timestamp when the token was minted
- jti (JWT ID) — Unique identifier for the token
3. Signing Algorithms
The alg header selects how the signature is produced. Choosing the wrong one is one of the most common JWT vulnerabilities.
- HS256 / HS384 / HS512 — HMAC with a shared secret. Fast and simple, ideal for monoliths and internal APIs.
- RS256 / RS384 / RS512 — RSA signature. Asymmetric: the issuer signs with a private key, anyone with the public key can verify.
- ES256 / ES384 / ES512 — ECDSA over the NIST curves P-256, P-384, P-521. Same asymmetric model but with much shorter signatures.
- none — a special algorithm with no signature. Never accept tokens with
"alg":"none"; this is the classic JWT vulnerability.
4. Security Best Practices
- Always validate the signature. Decoding the payload tells you nothing about trust.
- Reject
alg: noneand enforce algorithm whitelisting. Specify exactly which algorithms your service accepts. - Keep tokens short-lived. Issue access tokens that expire in 5–15 minutes.
- Do not put secrets in the payload. The payload is Base64, not encrypted.
- Validate
iss,aud, andexpon every request. - Use TLS everywhere. JWTs in transit over plaintext HTTP can be intercepted.
5. Common Pitfalls
- Clock skew. Allow a small leeway (30–60 seconds) when comparing
expandnbf. - Algorithm confusion. Always pin the expected algorithm in code.
- Token leakage via logs. Configure your logging stack to redact JWTs.
- Confusion between ID tokens and access tokens. Using an ID token as a bearer token for an API is a common anti-pattern.
Header, Payload, Signature, All in the Open
Done right, the whole operation takes seconds, runs entirely in your browser, and never uploads a byte of your input. For anatomy of a JSON Web Token — or anywhere a precise, in-browser result beats a heavier install — this tool is the right one.