Stop Using JWTs • Hacker News Board

Re: Stop Using JWTs

#61

Post by robertlagrant » Tue, Jun 16, 2026, 8:10 PM UTC

RagingCactus wrote: post #16

solatic wrote: post #3

Necessary qualifier: for browser-based user sessions. Plenty of good uses for JWTs for service-to-service communication. edit: I read some of the linked stuff, e.g. https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... . Please, if JWTs are such a horrifically insecure standard, go ahead and publish your means for hacking AWS STS's AssumeRoleWithWebIdentity , or don't publish and just exploit it by launchin…

> Necessary qualifier: for browser-based user sessions. > Plenty of good uses for JWTs for service-to-service communication. This is the sensible conclusion right there. I agree JWTs are the wrong tool for the use case of user sessions in the browser. To give some more arguments: All the signature and encryption stuff in JWTs is complex. While common JWT libraries have now mostly got their stuff together, this has no…

> While common JWT libraries have now mostly got their stuff together, this has not always been the case. There were plenty of libraries accepting the "none" algorithm [1] or allowing attackers to forge tokens by using a public key as a shared secret [2]. This is the direct result of the complexity criticized in the linked blog post.

I'm a bit surprised at this. These are extremely simple to solve - the first time I ever did a JWT-reading implementation I specified the right defaults, which are very simple, even for a mid-level backend person I would say, and they haven't needed changing in 8 years or whatever it's been. It really isn't very complex.

Re: Stop Using JWTs

#62

Post by littlecranky67 » Tue, Jun 16, 2026, 8:10 PM UTC

doctorpangloss wrote: post #59

littlecranky67 wrote: post #49

Earlier quoted context omitted.

Yeah of course, but how does that relate to my point? With JWTs you don'T have a list of valid tokens as state, but only a list of invalid ones (revoked). But the list of revoked tokens in the last X hours (where X is your token lifetime) is always going to be smaller than the list of active sessions given a large enough user base. Hence my original point stands, that the lookup and storage costs are lower than on se…

isn't it that you must have a revocation list in many cases? if you cannot get from N to 1 or 1 to 0 states, if you're just going from N to N-1>1, you haven't materially decreased your statefulness

But the revokation list is always going to be orders of magnitude smaller than the list of active sessions.

Re: Stop Using JWTs

#63

Post by agwa » Tue, Jun 16, 2026, 8:12 PM UTC

hparadiz wrote: post #50

agwa wrote: post #47

Earlier quoted context omitted.

Fair enough, but those optimizations are basically free. People think stateless tokens are free but they really are not.

The cost of the stateless token is basically the CPU usage for signing the message and checking the signature with the public key on the client. Example: Google Compute Instance asks metadata server for OIDC token (which is a JWT). The metadata server respond with the token that basically says "here's the machine service account, here's the machines ID, this token is proof that I am service account abc123 and it's va…

The cost is the vigilance required to use them safely. It's not just compute/storage costs.

Re: Stop Using JWTs

#64

Post by kobalsky » Tue, Jun 16, 2026, 8:14 PM UTC

I agree that using cookies is better for web sessions but I absolutely despise those using the boogeyman to shoo people away from stuff they don't like, instead of asking them to use their brains.

> they are not secure.

They are secure if they fit your risk profile, a blanket statement like this is just disinformation.

Don't treat your peers like idiots.

Re: Stop Using JWTs

#65

Post by agwa » Tue, Jun 16, 2026, 8:15 PM UTC

robertlagrant wrote: post #61

RagingCactus wrote: post #16

Earlier quoted context omitted.

> Necessary qualifier: for browser-based user sessions. > Plenty of good uses for JWTs for service-to-service communication. This is the sensible conclusion right there. I agree JWTs are the wrong tool for the use case of user sessions in the browser. To give some more arguments: All the signature and encryption stuff in JWTs is complex. While common JWT libraries have now mostly got their stuff together, this has no…

> While common JWT libraries have now mostly got their stuff together, this has not always been the case. There were plenty of libraries accepting the "none" algorithm [1] or allowing attackers to forge tokens by using a public key as a shared secret [2]. This is the direct result of the complexity criticized in the linked blog post. I'm a bit surprised at this. These are extremely simple to solve - the first time I…

You would think so, but even an authentication company screwed it up:

https://cybercx.co.nz/blog/json-web-token-validation-bypass-...

Re: Stop Using JWTs

#66

Post by littlecranky67 » Tue, Jun 16, 2026, 8:17 PM UTC

dariosalvi78 wrote: post #28

szmarczak wrote: post #10

No need to stop. The XSS argument also applies when using cookies. JWTs are just tokens like session data but in JSON format. What format you choose to go with doesn't matter. You can keep storing JWTs in local storage and still be secure. Discord removes it on page load and restores it when the tab is closed. Also if your website is susceptible to XSS, skill issue, exactly like in the case of SQL injections. That wo…

with cookies you can restrict them to HttpOnly so that they are not exposed to client-side scripts. This reduces the chances of XSS to access the long-lived access tokens (JWT or session ids).

This. I store my JWT in a cookie, and the cookie is of course set to HttpOnly,Secure and SameSite=strict. That basically kills XSS. I do not use openid connect, and one of my pet peeves with OIDC is that the access/refresh tokens are always exposed to the JS side (not in a cookie using HttpOnly) in any impl. i've seen.

Re: Stop Using JWTs

#67

Post by LgWoodenBadger » Tue, Jun 16, 2026, 8:21 PM UTC

RagingCactus wrote: post #16

solatic wrote: post #3

Necessary qualifier: for browser-based user sessions. Plenty of good uses for JWTs for service-to-service communication. edit: I read some of the linked stuff, e.g. https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... . Please, if JWTs are such a horrifically insecure standard, go ahead and publish your means for hacking AWS STS's AssumeRoleWithWebIdentity , or don't publish and just exploit it by launchin…

> Necessary qualifier: for browser-based user sessions. > Plenty of good uses for JWTs for service-to-service communication. This is the sensible conclusion right there. I agree JWTs are the wrong tool for the use case of user sessions in the browser. To give some more arguments: All the signature and encryption stuff in JWTs is complex. While common JWT libraries have now mostly got their stuff together, this has no…

Come on, it’s not like the two are even within the same magnitude or three

“But if you have to check an identifier for revocation on every request you could just use an opaque session ID and look that up on every request instead!”

Re: Stop Using JWTs

#68

Post by zsoltkacsandi » Tue, Jun 16, 2026, 8:24 PM UTC

littlecranky67 wrote: post #49

zsoltkacsandi wrote: post #44

Earlier quoted context omitted.

> JWTs have a limited expiry timestamp, so you only ever need to maintain a revocation list for tokens not expired yet. Sessions have expiration timestamps too, and you can configure them however you like.

Yeah of course, but how does that relate to my point? With JWTs you don'T have a list of valid tokens as state, but only a list of invalid ones (revoked). But the list of revoked tokens in the last X hours (where X is your token lifetime) is always going to be smaller than the list of active sessions given a large enough user base. Hence my original point stands, that the lookup and storage costs are lower than on se…

> With JWTs you don'T have a list of valid tokens as state, but only a list of invalid ones (revoked).

Yes, and a lookup operation is a lookup operation.

Your database or data structure used for storing the sessions/JWT revocation entries won't really care whether you look for things that are active or things that are inactive/revoked. If you store it in the right database, both lookups will be O(1), so it is the same (or at least the difference is negligible), regardless of the size.

Re: Stop Using JWTs

#69

Post by misano » Tue, Jun 16, 2026, 8:29 PM UTC

imo instead of random cookie u can carry some data in it and avoid more joins in database why not ?

Re: Stop Using JWTs

#70

Post by vova_hn2 » Tue, Jun 16, 2026, 8:32 PM UTC

littlecranky67 wrote: post #34

vova_hn2 wrote: post #29

Earlier quoted context omitted.

> your validation logic simply should refuse any token before $NOW. Well, this approach throws out a lot of babies with the bathwater. You invalidate tons of legitimate tokens along with the one that you wanted to invalidate and get a thundering herd [0] of clients wishing to re-authenticate. This is probably not good in case of a really high load. And if you don't have a really high load, then there is no good reaso…

I edited my comment after I posted it to clearify you do this on a per-identity basis. I.e. every user/identity has a minimum_issued_at field. A user can "sign out from all devices", and that will simply update minimum_issued_at with $NOW. You are not throwing out a lot of babies with the bathwater if you would do it in a case of a known attack. You would invalidate ALL tokens of a user, which is a sane default espec…

Thanks for the correction, I didn't think about this approach and it sounds like it should work.

The only comment that I have that if you are already querying users table (or collection in case of NoSQL or whatever), you might as well have a sessions table/collection in the same database/storage and query them together. It seems that difference is not that big.

The purported advantage of stateless sessions is that you can check the auth without querying the main db/storage (maybe only querying a smaller/faster axillary storage).