Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The article misses the point of JWT: it's dead simple to implement.

I don't implement JWT because I fancy big data terascale technologies. I do it because it's mostly stateless, meaning it's very easy to mock locally, and easy to deploy.

> You wanted to implement log-out, so now you’re keeping an allowlist of valid JWTs, or a denylist of revoked JWTs. To check this you hit the database on each request.

No, you just remove the JWT from the local storage. Sure, the user could then relogin if he copied it, but if it's on his own will, why not. And if he got his JWT stolen before logout, bah anyway any token could have been stolen that way, whatever the tech.

> You need to be able to block users entirely, so you check a “user active” flag in the database. You hit the database on each request.

Right but that contradicts the whole premise of the article, being that you probably don't need fancy features. 99.9% of websites don't need to ban users _instantly_. If you have a fair JWT expiration, it's usually OK.

I'd argue for the exact opposite of the article. If you want dead simple Auth, without fancy tech, just use JWT.




> And if he got his JWT stolen before logout, bah anyway any token could have been stolen that way, whatever the tech.

The thing is, with the good old "token in the database" method, logging out means deleting the token from the database so no, you can’t reuse a stolen token after a logout.


If the user can somehow get their token stolen from the browser, they can also get their username/password stolen from the browser.


Plus, a compromised browser could just block the logout request. It's a nonsense and indefensible threat model. If you need to worry about compromised browsers, you need a mitigation which doesn't rely on the browser or that'd be easily compromised by someone who could compromise the browser.

It's a slightly different story with a "logout all sessions" button where the user might press it from a trusted device, but that's a different functionality than a logout button. There you would need revocation, but if you (like many websites) don't actually support this functionality you really don't even need to support a logout functionality more complex than just asking the client nicely to please delete the token.


What if you want to implement logging out all user sessions?

You'd have to store something somewhere, so you end up losing the benefits of stateless authentication.


You could probably rotate the secret which would invalidate all existing sessions.


That would log out all users. That'd be pretty annoying.


That's a fancy feature. The article is all about sticking to what is simple and without fancy features


No, it's a necessary feature if your credentials get stolen, which wouldn't surprise me considering how many people just cram JWTs into local storage, which is not the same as a secure cookie and has weaker security. Either you're setting the expiry time real low (which still won't stop someone who has four minutes 59 seconds left to wreck your stuff, because computers are fast), or you're maintaining a blacklist, which means, congratulations, you've just reinvented overly-complicated session tokens.


> The article misses the point of JWT: it's dead simple to implement.

Implementing it securely, however, is far from dead simple.

https://scottarc.blog/2023/09/06/how-to-write-a-secure-jwt-l...




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: