Wouldn't you just need a list of logged-out JWTs? And maintain entries until the JWT would have expired?.
And that's if you really cared. Some people would be fine with the client and server participating in the log out and a low-ish JWT expiry.
Sure, but that's not a real improvement. It's still stateful since you need to check the list with every request, you can't just verify the signature. Changing the logic from "must be in this list" versus "must not be in this list" does not give you much -- maybe some performance gain, depending on the situation.
> And that's if you really cared.
Well, that's my point. Developers may not care, but from the point of view of a security auditor, it's a vulnerability in your auth system, so the GRC/Security people do care, even if Foo start up doesn't. At some point, if Foo is successful, they will face this issue and need to support real logout to get the certifications they need to do business or be in compliance.
You can verify the signature before calling the DB.
As someone who implements this exact solution, it actually gives you a lot. If your JWTs have a relatively small timeout window (say N minutes), then that means the number of expired tokens you have to keep track of is usually very small (e.g. for everyone who clicks the logout button with a valid token you have to keep that token around for at most N minutes), and on many websites the average user never makes an explicit logout request.
So that means that in many (most?) usage scenarios you can just replicate the list of recently expired tokens to your servers (easy with something like Redis) and then just check incoming requests against that in-memory list. Again, this isn't anything special or new, it is discussed in the article.
This is very different from storying the list of every valid JWT, which will often times be much bigger than you can store in memory.
Similar security to "abandoned session" which is of course what a very large % of users do instead of "logging out".
There is risk of cloned session, but there's no law saying non-banking apps have to care.
This has the nice property that if you're forced to, adding a cache to store invalidated tokens with a ttl of 10 minutes is an incremental enhancement.