The stateless dilemma
A signed token is valid until it expires because verification needs no server lookup. That is great for scale but bad when you must revoke access immediately, such as on logout or account compromise. Several strategies reconcile this.
Short lifetimes plus refresh
The simplest approach keeps access tokens short lived, perhaps minutes, paired with refresh tokens. Revocation then means refusing to issue new access tokens. The window of exposure shrinks to one access token lifetime rather than becoming instant.
Denylists
For immediate revocation you reintroduce some state. A denylist stores identifiers, the jti claim, of revoked tokens. Each request checks the denylist before trusting the token. This is small because it only holds tokens revoked before their natural expiry, and entries can be evicted once expired.
Token versioning
Another option stores a token version per user. Tokens embed the version at issue time, and a request is rejected if the embedded version is older than the current one. Bumping the version invalidates all of a user's tokens at once, useful after a password change.
Key idea
Pure stateless tokens cannot be revoked instantly, so systems use short lifetimes, a denylist of revoked ids, or per user versioning to regain control.