Your JWT is valid for an hour. Someone steals it at minute 2. What happens?

most auth setups issue a JWT and move on. the token is valid, the user is in, done.

but here's the scenario nobody wants to think about: the token gets stolen. maybe a compromised device, a leaked log, a man-in-the-middle on an untrusted network. doesn't matter how. it's out there now.

and it's valid for another 58 minutes.

a self-contained JWT has no phone-home. the API just checks the signature and the expiry.

it has no idea the token is in the wrong hands. you can't revoke it. you can't block it. you just wait it out.

the usual answer is 'make tokens short-lived.' but short-lived tokens mean more refresh cycles, more friction, more infrastructure. and even a 5-minute token is a 5-minute window.

the real fix is token revocation that actually works in real time. session-bound tokens, live introspection, back-channel logout that propagates everywhere the moment you pull the trigger.

curious how people are handling this today.

are you accepting the risk of JWT expiry windows, or have you actually solved real-time revocation in your stack?

14 views

Add a comment

Replies

Best

Short-lived access tokens + refresh-token rotation seems like the practical middle ground for most apps.Real time introspection can be useful,but adding that complexity everywhere feels hard to justify unless the threat model really needs it.