So instead of storing all session tokens indefinitely, you only store invalidated tokens for a short period of time.
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.
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...
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.