Curiousity killed the cat, but not me!

[chasen-bettinger]

Fantastic list! I learned a lot from reading, thank you for putting it together.

Two asks:

1. Could you expand upon 'Suggesting expiration for JWT tokens'? I'm not following the advice that's written. I've always recommended short expiration amounts due to the risk of the JWT being exposed.

2. Do you have a shortlist of emerging threats that practitioners should be paying attention to?

[sandeepl337]

What’s the issue for JWT?
JWTs are stateless tokens with exp in their payload. They don’t require server-side session storage. Yet, some reports wrongly suggest adding manual expiration or revocation, which goes against their purpose. JWTs avoid session management for better performance. Adding manual revocation adds complexity and defeats this purpose.

When does manual revocation make sense?
In high-security cases (e.g., compromised tokens), a hybrid system like a revocation list or refresh tokens may help. These are edge cases, not standard JWT usage.

Better recommendation would be implement refresh tokens and Manage long sessions with server-side control.

[sandeepl337]

Hmm threat and also business point of view:

1. Tokens with overly short lifetimes may force frequent reauthentication, frustrating users and leading to insecure workarounds (e.g., hardcoding tokens).
2. Long-lived tokens remain valid even after user logout or compromise, increasing the risk of misuse.
3. Some systems skip exp claim validation, allowing expired tokens to be accepted.
4. Attackers modify the exp claim in unsigned or improperly verified tokens to extend validity. (If it is unsigned you can more other stuff too.)

[vladko312]

Can't fully agree here. JWTs are supposed to be stateless, but what they represent (sessions and privileges) is often stateful. Information security should always be about the impact on the target, not about ideology/properties of some solutions used by that target.
Stateless nature of JWTs allow applications to use them as a client-sire signed storage for basic permissions information as well as some profile data, but it doesn't mean that the application should build it's session management around a completely stateless JWT model.
Session revocation is often required at least in some form, and JWT tokens by their nature can simplify it. For example, short session time can be used with token refreshing, where session expiration would only affect the refreshing process.
Another way of combining JWTs and sessions is storing small session id inside a JWT token. This requires slightly more resources from the application.
It is still within the JWT stateless model: JWT token serves as a stateless storage for session data like a session id, permissions list and basic account info. At the same time, session revocation (and maybe even expiration) is separate from the token itself.
One of the few situations where stateless ideology of JWTs really needs no server side revocation is a fully stateless application. For example, it might be a game where JWT is used as a save file. Those cases are rare and often not security critical anyways.