Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Using JWTs

gist.github.com

Post reply on HN
Print view View original

81–90 of 335 posts

Re: Stop Using JWTs

#81

Post by doctorpangloss »

littlecranky67 wrote: post #62
doctorpangloss wrote: post #59

Earlier quoted context omitted.

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.

that may be, but who cares how big or small it is really

if you are facebook sized, with 1b+ active sessions versus an alternative with 10m+ revocations... the kind of applications that reach this scale, they have enormous amounts of state anyway.

Re: Stop Using JWTs

#82

Post by mewpmewp2 »

jpalomaki wrote: post #45
littlecranky67 wrote: post #40

In sessions vs. JWT revocation lists, there is an argument in favor of JWT revocation lists. JWTs have a limited expiry timestamp, so you only ever need to maintain a revocation list for tokens not expired yet. Given that you probably only have a fraction of JWTs revoked compare to valid JWTs in circulation, you only need to query a very small dataset for each request. When using sessions, your list of valid sessions…

Session data lookup is one select to database that gives 0..1 rows and uses index. In most cases this is not something you need to worry about.

If you have multiple services in multiple locations however, you may want to replicate this data, so in this case revocation list as it's much smaller would be far easier to replicate for much less latency overhead.

Re: Stop Using JWTs

#83

Post by hparadiz »

agwa wrote: post #63
hparadiz wrote: post #50

Earlier quoted context omitted.

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.

I didn't downvote you. You're absolutely right. Implementation of anything is work.

Re: Stop Using JWTs

#84

Post by chuckadams »

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…

A revocation list defeats the purpose of JWTs. If you find yourself needing one, JWTs were probably the wrong choice to begin with.

Re: Stop Using JWTs

#85

Post by BlackFly »

If I understand the point being made here then the idea is that a stateless session via a cryptographically verified bearer token needs a stateful revocation list to eliminate hijacking (a user logout should completely invalidate the login but a bearer token would otherwise continue to be valid) and if you are maintaining state then you can just use a complete stateful session and avoid the complexity of the cryptography.

This point is not made very clearly and is buried by overemphasising JWTs instead of just quickly pointing them out as an example of a stateless session. But yeah, it is a good point.

Re: Stop Using JWTs

#86

Post by littlecranky67 »

doctorpangloss wrote: post #81
littlecranky67 wrote: post #62

Earlier quoted context omitted.

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

that may be, but who cares how big or small it is really if you are facebook sized, with 1b+ active sessions versus an alternative with 10m+ revocations... the kind of applications that reach this scale, they have enormous amounts of state anyway.

Everybody thinks Mag7 scale, but actually it is more relevant if you are a tiny webservice - but available world wide. If you need to match each and every http request from a user half way around the world against a central db, you can't beat the speed of light. If you can do authentication on each downstream server directly using crypto and JWT validation, you at least save that roundtrip to the session db. The revocation list is tiny (a few megabytes tops), append-only, can be public to the world, and thus easy to replicate to your downstream nodes.

If you are a smaller gig, you won't have to bother with replicating your sessions and keeping them in sync globally.

Re: Stop Using JWTs

#87

Post by jkrejcha »

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…

A lot of times local storage is much less secure than using cookies. Cookies have about 20 years of infra built around it (HttpOnly, SameSite, Secure, etc). There's some weird parts about cookies, but local storage really shouldn't be used for anything security sensitive

Re: Stop Using JWTs

#88

Post by rdegges »

=0 I stumbled across this post and was thinking that it's interesting to see this topic trending now, since I've done a lot of work on it in the past. Then I clicked through and realized the author is linking to some of my stuff! What a blast from the past.

Anyhow, there are way smarter people than myself who have covered this topic extensively over the years, but I still think that, even in 2026, JWTs are the wrong tools for web auth. They're fine to use for service-to-service stuff, but if you have the option, just use PASETO -- it solves a lot of the issues!

Re: Stop Using JWTs

#90

Post by jkrejcha »

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…

JOSE can still have problems if it's secure when implemented properly. A lot of API surfaces for them can kinda suck. If secure when held right was equivalent to good, then that would apply also to stuff like X.509

There are better alternatives for a lot of cases, standard session tokens or API keys are a popular one in use in most major websites online and work pretty much perfectly for most use cases.

I'm not gonna say those standards are completely without merit. The best thing about them is that it is some basic standard on passing stuff around that isn't like ASN.1 encoded or whatever, to which the tooling seems incredibly brittle and bug-prone.

Post reply on HN