JWT (JSON Web Token)

What is a JWT?

A JSON Web Token packs claims (subject, issuer, expiry, roles) into a base64-encoded, cryptographically signed payload: header.payload.signature. Any service holding the public key verifies authenticity locally — no session-store lookup — which is why JWTs power OAuth/OIDC flows and stateless API auth everywhere. The signature guarantee is integrity, not secrecy: payloads are readable by anyone; JWTs are tamper-evident postcards, not sealed envelopes.

The trade everyone signs, few read

Statelessness cuts both ways. No lookup per request is the scaling win; no revocation is the price. A stolen token is valid until expiry — logout, password change, and account suspension do not invalidate already-issued JWTs. The standard architecture accepts this deliberately: short-lived access tokens (5–15 min) + long-lived revocable refresh tokens, bounding stolen-token damage to minutes. Long-lived access JWTs recreate sessions minus the ability to end them — the worst of both designs.

Verification is a checklist, not a step

Real-world JWT breaches are almost all verification bugs, and the classics still circulate: accepting alg: none; algorithm-confusion attacks (validating an HMAC token against an RSA public key); skipping audience/issuer checks so a token minted for one service replays against another; trusting expiry client-side only. Use a maintained library, pin expected algorithms, validate iss, aud, exp — every time, every service.

What people get wrong

• Sensitive data in claims — payloads are public; PII in a JWT is PII in every log that captures a header.
• localStorage as token home: one XSS equals token theft; httpOnly cookies or in-memory storage narrow the blast radius.
• JWTs where sessions belong — a monolith with one database gains nothing from statelessness and loses revocation for free.

Primary source: RFC 7519 — JSON Web Token