JWTs - Patterns & Anti-patterns

The talk gives a practical tour of JSON Web Tokens, starting with their three parts: a header, a claims payload and a signature. It separates terms that people often mix up, such as HTTP cookies, traditional random session keys and stateless tokens, and explains why teams adopt JWTs, mainly to avoid database lookups on every request and to pass identity between internal services.

The middle section walks through common anti-patterns. These include accepting the "none" algorithm, placing sensitive data in claims that anyone can decode, keeping tokens in local storage, using weak or reused HMAC secrets, and issuing tokens with no expiration or no way to revoke them. Revocation tables bring back the database lookups the design was meant to avoid, while homegrown refresh-and-access token schemes and fragile key rotation add complexity with little security gain.

The closing section offers safer approaches. Hardcoding the expected algorithm, relying on maintained libraries, and setting registered claims such as expiration, issuer, subject and key ID all reduce risk. A short-lived deny list in a cache with TTLs can limit the cost of revocation. The speaker suggests that plain session tokens or alternatives such as Macaroons often fit better than JWTs for sessions, and points to RFC 8725 as a best-practice reference.