Comment by AndrewSChapman | Hacker News Reader

Comment by AndrewSChapman | Hacker News Reader

Parent Full thread

I'm not 100% sold. I think JWT's are fine in some situations as long as you know the limitations.

Regarding session invalidation, I would handle this in two ways.

1. Support a "Log everyone out" function by storing a simple version number in the JWT. If the version constant in your app is different to the number in the JWT, it is invalid.

2. Support a "I need to logout user X function" by storing a blacklist of tokens in your RDBMS. If your RDBMS goes down, you have much bigger problems. A blacklist will be very short, and often completely empty, so lookups will be significantly faster than checking a session table. You could also use Redis or an application cache for storing the blacklist, with an RDBMS fallback.

Regarding storage, there's nothing stopping you putting your JWT into a cookie with the HTTPonly flag set. So long as you're not storing too much in token, they will be less than 4k and so will fit.

> 1. Support a "Log everyone out" function by storing a simple version number in the JWT. If the version constant in your app is different to the number in the JWT, it is invalid.

If you've got the iat property, you could just use that. i.e. anything issued before x time is invalid.

Well, the RDBMS solution is precisely a stateful infrastructure that (the author claims) “defeats the entire point of using stateless JWT tokens.”

>>2. Support a "I need to logout user X function" by storing a blacklist of tokens in your RDBMS.

Again though, the whole point of JWT is to completely avoid server-side state management. The moment you store state somewhere (whether a list of valid tokens or a shorter list of invalid tokens) you have re-invented the concept of sessions, so why not use that instead?

How about instead of "the whole point of JWT is to completely avoid server-side state management" we think of it as "the whole point of JWT is to reduce the overheads of server-side state management".

In my answer above, I was pretty clear about how the load on the database can be significantly reduced with a blacklist and optionally Redis out front, thus allowing JWT to significantly reduce the burden on the database.

Why would the lookups be faster in a small/empty table? If the lookup is by indexed ID it should be trivially fast either way.

Furthermore, you can store the session information in Redis by ID, too, to reduce DB burden.

Reply on news.ycombinator.com