Hacker News new | ask | show | jobs
by istvanp 2845 days ago
One of the biggest downsides in my opinion is that session invalidation becomes non-trivial. Your best bet (assuming you don't want to do any additional network requests) is to reduce the session length to the smallest amount you (or users, depending) will tolerate and perform some kind of re-authentication; i.e. force a logout and do a fresh login or check if they can get a new token based on the old one transparently. For example, a user changing their password should kill all tokens that are in use immediately for good security. You can't do that with JWT. All tokens will stay valid until they expire.
1 comments

I haven't used JWT but the way you solve this is by having a refresh token that lasts several days that lets you "login" without a password. The refresh token is then used to get the real session token with has a low expiration, perhaps 5 minutes. When the session token expires you just "login" again.

But honestly I don't see the need for the vast majority of applications. Most frameworks cache the permissions, etc on login so the database doesn't have to be accessed on every request.