[hunterb123]

Because you're only storing the invalidated tokens and you're only storing them for the length of the token's lifetime (expire the redis key when the JWT expires)

So instead of storing all session tokens indefinitely, you only store invalidated tokens for a short period of time.

[ravenstine]

Since when were session tokens ever a bottleneck? That's a problem I've never heard of on any scale. Yet again, JWT seems to be trying to solve a non-problem. Session tokens don't even have to be stored indefinitely. If a user isn't active for a period of time (even 30 days let's say) then the session token can be removed. Or, if memory truly was a problem for session tokens (not sure why honestly), transition tokens to storage after x amount of time and bring them back into memory when the user is active again.

[adolph]

> Since when were session tokens ever a bottleneck?

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).

http://hl7.org/fhir/smart-app-launch/index.html

[magicalhippo]

Here in Norway, the gov't is using it the same role[1], where they have a single agency (Digdir) handling authorization, so that the other agencies don't have to deal with that and can just implement their APIs.

[1]: https://docs.digdir.no/docs/Maskinporten/maskinporten_summar...

[hunterb123]

I simply explained the efficiency difference of the two setups.

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.

[marcosdumay]

Well, on the other hand, you will have to distribute that revocation list somehow, what does add some complexity to your code.

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.

[hunterb123]

Redis is pretty easy to distribute out of the box.

And most likely you'll want a simple k/v distributed cache for other things so it's no extra work.

[dontlaugh]

But then you can just put your session data in Redis. You're eating the latency to Redis either way.

[jayd16]

It's quite common. If you have an outage where your sessions are cleared, you can hit issues where all your users DDOS your auth service. If you persist the sessions you have the same problem except they DDOS the DB.

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.

[ravenstine]

> If you have an outage where your sessions are cleared

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.

[jayd16]

>Why would that even be allowed to happen in the first place?

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.

[eagsalazar2]

This "the invalidated JWTs list is smaller" argument really doesn't hold water. Size of cache is a red herring (unless you are facebook or something). 99.99% of the time the most important variables are simplicity and security, surface area for dev errors or attacks. Smaller invalid cache fails on those fronts and only is superior in ways that don't actually matter.

[hunterb123]

I answered those talking points here:

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.