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.
Yes but if each microservice needs to check a cache on each request, then why use jwt at all, you could just save a classic session (with random token) in that cache as well
The redis cache with invalidated tokens will be much smaller than storing all sessions.
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.
It depends on your scale, but even at small scale, your central auth database is something that needs to be highly available because your whole system is down otherwise.
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.
"Yes but then ... why use jwt at all, you could just save a classic session (with random token) in that cache as well".
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.
As explained in the article, if that's the case then you can't really trust the JWT anymore only for it's cryptographic signature and you rely on an internal store entry that makes the token valid / invalid.
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.
That's discussed in the article in the second paragraph under "Problems with JWT". If you're keeping a cache at each server node then you might as well just use bearer tokens.
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.
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.
> 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).
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.
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.
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.
> 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.
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.