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

201–210 of 335 posts

Re: Stop Using JWTs

#201

Post by locknitpicker »

agwa wrote: post #47
hparadiz wrote: post #42

Earlier quoted context omitted.

You should do some basic optimizations. Fixed length table and indexes on the unique string for fast lookups. I also like to do a rolling delete for old sessions after 30 days unless mobile session that is logged in. Those get to live forever.

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

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

Strawman.

The only requirement for a JWT is posting the JSON Web Key set with the public keys used to verify the JWTs signature. That's the full cost of a no-frills JWT implementation of you exclude IAM.

If you want to have one-time JWTs you need to maintain a revocation list. This is literally a set of IDs. If you go nuts and use GUIs for JWT IDs that means each entry takes as much space as 4 ints, and all you need is a set membership check on said integer. Even at FANG scale you can handle that scale in a memory cache service such as ValKey running on a COTS desktop.

Now show us your alternative.

Re: Stop Using JWTs

#202

Post by ChicagoDave »

tomjakubowski wrote: post #175
ChicagoDave wrote: post #163

OAuth2 has been the web security standard for ten years. I don’t recall any major security announcements about it. The OP is confused.

I'm confused. What does OAuth have to do with JWTs? They seem orthogonal: OAuth2 doesn't specify a format for access tokens, nor does it require statelessness.

I guess I just assume a good architect would enforce authorization with an identity server and never put anything important on the client.

Re: Stop Using JWTs

#203

Post by beckler »

hparadiz wrote: post #21
tracker1 wrote: post #9

JWTs are insecure... even when using trusted, rsa/ppk based signing methods? not shared secrets. JWTs are too long lived... Nothing is stopping you from limiting the JWT lifetime and having a refresh model against an authentication authority... I mean, even if you use cookie based sessions, you're storing somewhere... you can have a jwt valid for 5-15min. 15minutes is roughly the cache timing for many authorization s…

You can make a JWT invalid after 30 seconds or even 1 second. You should set an aud (audience) when creating the JWT. Otherwise the signature is crypto-graphically sound. Validate every single JWT every single time with a short lifetime. OIDC tokens are all JWTs btw.

The ID token is always a JWT when doing OIDC, and it makes sense in this situation.

Because the ID token is not a set of credentials, but signed information you’d use to create/update a user’s profile.

You can technically use JWTs as access tokens, as the spec doesn’t specify a format for access tokens, but in my experience they’re normally opaque bearer tokens.

Re: Stop Using JWTs

#204

Post by mawadev »

andy_ppp wrote: post #143

Okay, so hack into a site that uses JWTs for login, if it’s so insecure we should be seeing loads of attacks against them right? Stolen tokens everywhere being used to impersonate people and other things. For example I believe ChatGPT is using Auth0 which uses JWTs, so you can hack this insecure token system? Should be easy right given the extremity of the warning that JWT is the big problem here.

Finally, feels like the blog stirs up unnecessary drama

Re: Stop Using JWTs

#205

Post by Aldipower »

Man, once a year the same BS. JWT in an secure HTTP only cookie are perfectly fine, not less secure then a regular a regular session id, but indeed give you the advantage being able to be stateless!

Re: Stop Using JWTs

#206

Post by jongjong »

RagingCactus wrote: post #196
jongjong wrote: post #183

Earlier quoted context omitted.

The people who are upset about JWTs probably got burned by trying to use them in a weird way. Some people try to store sensitive data inside JWTs... WTF, the idea would never have entered my mind! Sensitive data should stay on your server. Encrypted or not! JWTs are supposed to be signed, not encrypted! You shouldn't even think to put sensitive info in there. Also, WTF is wrong with people who accepted algorithm "non…

> Also, WTF is wrong with people who accepted algorithm "none." They dared to use the default validation function of their JWT library. They did not choose to accept "none". And the library authors implemented it because it's in the spec. It doesn't excuse that the default was to accept "none", but it is an explanation and in my opinion a valid critique of the standard.

Yeah well it's definitely a footgun built into the spec but ultimately an library implementation mistake.

Re: Stop Using JWTs

#207

Post by philt3r »

tored wrote: post #93
rdegges wrote: post #88

=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…

Invalid certificate - dark humor. https://www.paseto.io/

Go to https://paseto.io/ instead (without `www`), there is a TLS certificate there.

Re: Stop Using JWTs

#209

Post by Anoian »

ChicagoDave wrote: post #202
tomjakubowski wrote: post #175

Earlier quoted context omitted.

I'm confused. What does OAuth have to do with JWTs? They seem orthogonal: OAuth2 doesn't specify a format for access tokens, nor does it require statelessness.

I guess I just assume a good architect would enforce authorization with an identity server and never put anything important on the client.

How does an identity server store auth information with the user?

Re: Stop Using JWTs

#210

Post by unscaled »

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…

I think both you and GP are somewhat misrepresenting the OP is saying. OP's argument is three-fold:

1. JWTs are not a good fit for a session token (although there are several RFCs that are trying to shoe-horn JWTs into this use).

> TLDR: JWTs should not be used for keeping your user logged in. They are not designed for this purpose, they are not secure, and there is a much better tool which is designed for it: regular cookie sessions.

2. JWTs have other "valid" use cases that only need a very short-lived token (e.g. a transit token or a request signature) and don't need to care about user authentication, revocation, XSS etc.

3. But JWT should not be used even for the "valid" use cases, since you have better (read: less outrageously insecure) alternatives nowadays.

> Also note that "valid" usecases for JWTs at the end of the video can also be easily handled by other, better, and more secure tools. Specifically, PASETO

You've noted these issues yourself. There are many common vulnerabilities with JWT: alg=none, algorithm confusion and weak key brute-forcing, mandating weaker algorithms like RSA and ECDSA while making the best, fastest and easiest to implement algorithms like EdDSA "optional".

There are also other design deficiencies that JWT makes by trying to be a generic cryptographic envelope format rather than a token format: e.g. expiration can be omitted and this feature that caused some libraries to not verify expiration by default or have a different (and confusing) set of token parsing methods that do not enforce the expiry. PASETO is a better design that is secure against all of these issues. Sure, there are a few minor qualms I can find with PASETO (e.g. no mandatory key ID and no support for non-JSON payloads), but it's unlikely to face the same avalanche of CVEs we got with JWT libraries.

Post reply on HN