2 ms·
If your talking about a browser context, where the authority is separate from the requesting body, then expiring even at 30s is excessive for user context, let
by tracker1 4mo ago
If your talking about a browser context, where the authority is separate from the requesting body, then expiring even at 30s is excessive for user context, let alone every 1s or every request... you're effectively then inflating every single API request into 2 requests... one for a new token, then another to the API being called. This is irresponsible for not much gain in a user-facing context.
- hparadiz 4mo agoYou should not be using them for user contexts at all. The cookie should be the session token and the sessions should be stored on the server side where you can simply delete them and the user's login becomes invalid. Using JWTs for this use case is just plain wrong.
- tracker1 4mo agoI disagree with you and the article on this... I thought that was pretty clear. You can use a revocation list with JWT if necessary, and if your JWTs never last more than 15m you'll be fine.. and if your security window is tighter than that, you probably have bigger issues to deal with.
- hparadiz 4mo agoI think you can use a JWT just fine to introduce a new user into a system but once authenticated just set a classic session cookie with an expiration. I get when you can't for like an API and sure that's where JWTs are best. But a regular website? Not the biggest fan.
- tasuki 4mo ago> You can use a revocation list with JWT if necessary Yes and let me just add that in many cases the use case is such that a revocation list is not even needed and then JWTs are actually stateless and it's a small win for everyone.
- tracker1 4mo agoExactly... especially if the expiration is a tolerance window you can handle without revocation at all. I'm a pretty big fan for using it inter-service, APIs and SPA systems.
- stavros 4mo agoBut in that case you're just using sessions, and the JWT is a microoptimization to avoid hitting the DB every request.