I wonder if an extension to the concept of jwt that extends the cryptographics chain down into some hardware component such as a TPM or secure enclave is the right answer. Basically the payload of the token could contain a pubkey for checking a signature on the request payload. The logout button would then have two local effects on the client side: delete the token and tell the hardware component to forget the private key.
Well, hence (functional). Making the client forget a token sounds trivial. But there's a long tail of clients out there, and many cases where things might get more complicated.
Maybe I'm damaged from working in a regulated industry, but a (possibly malicious) client who went through the logout process and could prove someone else reused the token after logout might have a case. Or another of a myriad of unknown possibilities.
It's all very unnecessary. There's a reason we all used to invalidate trust server side. It's just so much easier to reason about.
Why would you need to revoke on logout? Forgetting seems to be enough in all cases except maybe SSO revocation because in all other cases you can (and indeed often must) trust the client to protect the credential.
I think you need to take this a step further and really define your threat model instead of being despaired :)
If an attacker is able to steal a victim's cookie database, their system (or at the very least, their browser) is already deeply compromised. It is very likely that an attacker with such capabilities could prevent your website from ever sending the logout request (install a browser extension which blocks it, inject into the render process to silently drop it, modify the cached JavaScript on disk to inject code into the site, etc.). The logout functionality only works insofar as you trust the client, and in any circumstances where the client's cookies could be stolen you really can't trust the client. So logout revocation is not really a meaningful security boundary.
How about the scenario of a stolen device that's logged into the service. The victim logs in on another computer to try and reset their password and lock the thief out of the compromised account.
This is a different feature than a simple logout button though (something along the lines of "sign me out everywhere"), and many (smaller) websites don't actually support this. As far as I can tell, the very website we're on doesn't support it :) The parallel use case is SSO invalidation where you may need to immediately revoke access to a service after an employee is terminated.
You would need revocation in this case. Implementing this is easier when you already have database backed tokens, but unless you intend to support these features JWT is a totally reasonable engineering decision.
You have to store invalidated tokens anywhere they might pass through a service, which means you have to persist them for as long you can predict that there expiry will last. Simply putting them in a memory database isn't 100% if that db gets flushed, and then you might start storing them in a disk database, which at that point, you might as well have just read the db in the first place using cookie auth.
In microservices, you generally have to put an invalidated JWT cache between every service, or compromised JWT's are just floating around your intranet.
I've worked at a plethora of places who have JWT's who have no invalidation strategy what so ever, the majority of developers think that when you log out and the user has forgotten the JWT then you are all good......
You can do what Google and everyone else does, which is store the revoked tokens. At scale this is easy to do efficiently and rarely requires a network request since the number of revoked unexpired tokens is small.
