Can't you keep a whitelist/blacklist of tokens in a memory cache like redis/memcached and go from there? As far as I know that is the standard practice to invalidate non expired sessions tokens.
And you can expire the invalidated keys faster (set the invalidated key expiration to the expiration of the JWT)
Not many people revoke sessions, but a lot of people create sessions. Much more efficient to only store and check revocations. The rest can be stateless.
Obviously the situation is the same when managing a token blacklist if you truly have a hard requirement that sessions be instantly invalidated at a specific point, but there's a good chance you don't. Maybe it's OK to presume signed tokens are still good for some amount of time if your blacklist server is unreachable, or maybe waiting until the JWT expires after 60 minutes is too long, but a one or two minute delay is acceptable. Or maybe you only check the blacklist for high-risk API requests.
It's not ideal. Invalidation is definitely a weakness of JWTs, but there's still a lot of value in baseline statelessness.
JWTs add complexity and have zero benefit. The author never said it can't be made to work, obviously it can. It's just completely pointless in most applications.
This makes no benefits as to bearer token or any random string that the server "knows" is a valid authenticated request via internal store, like a DB.
Makes it easy to track issued tokens and revoke them too.
So instead of storing all session tokens indefinitely, you only store invalidated tokens for a short period of time.
JWT allows for a user to authnz with a third party trusted by the second party. An example of this is HL7 FHIR SMART app launch, where an outside web application (2nd party) is opened from within an electronic medical records system (3rd party).
[1]: https://docs.digdir.no/docs/Maskinporten/maskinporten_summar...
You're storing and checking a smaller subset when doing stateless + invalidation cache.
Whether or not you need that memory optimization is up to you and your machines.
Personally it's about the same effort to implement and I prefer stateless + simple redis cache for invalidations.
If you are already distributing lists around your application servers (that impacts the format and top performance of the redis cache), then yes, it's quite simple.
And most likely you'll want a simple k/v distributed cache for other things so it's no extra work.
If you use JWT, users that get a new token are free to use your app without any further timeouts and reduce the load on the auth service. With a session system, the auth service reduces performance on the entire app.
Why would that even be allowed to happen in the first place? Sessions should always have some level of redundancy even if the primary retrieval is done in-memory. An outage would imply that an auth service is simply offline. Loss of sessions is a sign of catastrophic failure and possibly inadequate architecture.
> you can hit issues where all your users DDOS your auth service
Even in a case of a breach where all sessions must be cleared, JWT is one potential solution to mitigate DDOS. The others are to not have client-side code that blindly DDOSes your server and to have some level of DDOS protection in front of the rest of your architecture.
Moreover, even if you solve this problem for authentication, there's no obvious reason why you can't end up in a similar situation if some other service in your architecture is down. With JWT, all you've done is take the one service that is fundamentally one of the least complicated (storing hashes in memory) and treated it as if it's a critical point of failure. Sure, it can be, but auth is also one of the easiest things to horizontally scale, distribute, and synchronize at a relatively low cost. In JWT world, you've gone from storing even just random session numbers and now have to manage encryption keys, TTL, and possibly invalidation records (nearly defeating the entire purpose). That leaves even more room for things to go wrong.
> If you persist the sessions you have the same problem except they DDOS the DB.
Again, so what? You're supposed to do things to mitigate DDOS on your services regardless of whether you're using JWT. If your auth service can be that easily DDOSed (presuming this is an average website and not Facebook scale), then it would only take some coordinated enemies with a bone to pick to DDOS you without even using legit JWTs.
Not just failure, you could also see this with just big spikes in traffic like a release day.
Either way, sounds like you're convinced the cases are common enough that mitigations should be table stakes.
https://news.ycombinator.com/item?id=33020993
I disagree that stateful based sessions are simpler.
I disagree size of cache is a red herring.
You don't have to be FB to want to optimize your memory usage.
In the end I prefer the more efficient (mostly stateless) solution and it's really easy to implement.
But to each their own of course.