Authentication with JWT

JWT is presented everywhere as the modern authentication solution, and that reputation has a real basis: a signed token lets any service verify an identity without querying a database or sharing a session. For an architecture spread across several services, that is a considerable gain.

That same property is also its central flaw, and the point on which almost all tutorials stay silent: a JWT cannot be revoked. It is valid because its signature is valid, and that signature remains valid until the expiration written into the token. If a token leaks, if you fire someone, if a user changes their password after being compromised, the token keeps working. A server-side session, by contrast, can be deleted.

There are mitigations — short expiration, refresh token, blocklist — but each one reintroduces some of the state that JWT claimed to eliminate. Choosing JWT means accepting this trade-off knowingly, not avoiding the need to think it through.

This lesson therefore covers the token itself: its structure, its signature, the two classic attacks against naive implementations, its integration into Spring Security, and an honest treatment of client-side storage and revocation. The code uses Spring Boot 3, Spring Security 6, and Java 17.