I tend to think of sessions as one of those hangovers from the 1990s, when we couldn’t afford to “SELECT * FROM Permissions WHERE user_id=?” on every single HTTP request, that’d be crazy and overload the database server with disk I/O to those 10K RPM drives. So instead all sorts of strange lookaside caches got constructed, in the filesystem or in a KV store or in encrypted tokens or whatever … anything to avoid more disk seeks. Of course, the session ends up holding the superset of everything anyone every needs to know in a hurry, and then there’s cache invalidation to worry about …
In the meantime, memory sizes have increased so fast that it is very rarely worth worrying about this stuff … ‘hot’ session data is almost certainly in the row cache anyway, and if it isn’t it’s right there on an SSD. Just query what you need fresh from the DB every time.
(Obviously I’m not talking about being google/facebook/etc/etc, but if you’re making these decisions now, you aren’t google/facebook/etc/etc yet and you aren’t likely to be any time soon. Just develop something simple and get it in front of people and see if they like it.)
JWT solves session problems with microservices. Imagine 10 Services, which need to validate the session. So you will probably have to check the session at minimum 10 times / request. At scale this will produce much load und cache misses… IMHO
Is this still a current issue? https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
(2015 - many JWT libs allow attacker to specify ‘none’ as algorithm)
Apr 2015 commentary on JWT from tptacek: https://storify.com/jcuid/thomas-h-ptacek-don-t-use-json-web-tokens
The reasons you shouldn’t use JWT for sessions, is unrelated to these or other bugs (the article makes this clear).
It’s a consequence of the whole idea of self-verifying tokens, not something you can work around. You should not use a self-verifying token to do sessions because you need to be able to invalidate a session (think stolen passwords, devices etc). The invalidation list must be stored, and so you’re back to having a central service which verify sessions, negating one of the commonly stated benefits of JWTs.
It depends… Most of JWT libraries fixed this issue.