Hacker News Reader

That's not another way to put it. You can have a logout button which makes the client forget the jwt token.

But if the jwt was leaked before the client forgot it, the jwt itself is still valid and can continued to be used by an attacker.

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.

Reply on news.ycombinator.com