Tokens and JWT

A token carries its own claims, signed. The server does not need to remember anything: it verifies the signature and trusts the contents. That is the appeal, and it is also the problem.

You cannot revoke it. A signed token is valid until it expires, and there is no list to remove it from. Somebody signs out, and their token still works. You disable an account, and they keep their access until expiry.

The usual answer is short expiry plus a refresh token, at which point you are keeping server-side state to manage refresh tokens, which is the thing you adopted JWT to avoid.

✦ JWT is usually the wrong default

It is genuinely right for stateless service-to-service calls and for identity passed between separate systems. For a normal web application with a frontend and a backend you control, a session cookie is simpler, revocable and safer. Reaching for JWT because it appears modern is how applications end up unable to sign anybody out.

Where a token lives, if you have one. localStorage is readable by any script on your page, so a cross-site scripting bug becomes an account takeover. Memory is safer and lost on refresh. An HttpOnly cookie is safest and means you are most of the way back to sessions.

Decide deliberately and write down the reasoning, because this is the decision that most often gets made by copying a tutorial.