Live data from Hacker News

Stop Using JWTs

gist.github.com

141–150 of 335 posts

Re: Stop Using JWTs

#141

Earlier quoted context omitted.

And they've published updates[0] and libraries have hardened their defaults and removed support for insecure values (e.g. alg='none'). I'm not sure what more you want? I'd rather use a refined, battle-tested standard with lots of eyes on it than some new untested contender produced by a handful of upstarts ("look, we just designed it right from the beginning! This time it's perfect!") PASETO reeks of second-system sy…

I don't recommend PASETO either.

What do you recommend then? What technology has been designed, completed, then used for years without any updates or problems?

Re: Stop Using JWTs

#142
JWTs are extremely useful for storing basic non-secret authentication info. Session IDs are not as good for most situations and force unnecessary database or memory store lookups. JWT is a more versatile authentication construct because it doesn't prevent you from doing that extra lookup but it also doesn't force you to.

It's far better than a session ID in the sense that you can store an accountId inside a JWT and be confident about the identity of this user... The fact that you can get such confidence without any external lookups; just by looking at the token, is incredibly useful on its own. You can already seperate out unauthenticated guest users from authenticated users and you can tie their identities to real accounts without even checking the DB or session store. Banning is a separate concern. Being able to quickly, efficiently and reliably identify a user from the server-side is a necessity.

The only real downside of JWTs which people point to is that they cannot be easily be revoked... But if you really need the ability to revoke quickly, you can easily have 10 minute expiries on your tokens and request refresh every 3 minutes or so... So if you want to ban someone, there would be a 10 minute delay which is acceptable for the vast majority of scenarios... You should handle rate limiting as a separate concern anyway if spam is the issue.

For certain systems, a user may be making hundreds or thousands of requests in 10 minutes so you're saving a HUGE number of session ID lookups and it means that you don't need to run and maintain a separate Redis service or whatever else. Not to mention the additional latency which is added when you need to check Reddit before each operation.

These blanket statements against JWT are not new. People have been misusing them and blaming the tech because they don't want to acknowledge that they made implementation mistakes.

Any technology can be misused. It's foolish to misuse a perfectly good piece of tech and then use that as the basis to promote some alternative which has been through less battle-testing and which probably has even more gotchas which are yet to be discovered.

As a senior engineer with 15+ years of experience, I've seen this cycle over and over again. The new tech is always presented as fool proof and it never never never is.

Re: Stop Using JWTs

#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.

Re: Stop Using JWTs

#144
post #139
post #56

Earlier quoted context omitted.

If we stipulate that, we're still left wondering what the utility is of a standard that creates affordances for the insecure defaults, as opposed to just designing it right from the beginning.

> utility is of a standard that creates affordances for the insecure defaults You could make the same argument about Cookies. > as opposed to just designing it right from the beginning And generally, it's quite difficult to design it right from the beginning because one would often start with the wrong assumptions. Most standards evolve, and it should be acceptable.

No, that doesn't square up. It's like arguing "you could say the same thing about TCP, because it allows you to build JWTs, which are a bad protocol".

Re: Stop Using JWTs

#145

Earlier quoted context omitted.

I don't recommend PASETO either.

What do you recommend then? What technology has been designed, completed, then used for years without any updates or problems?

Bearer tokens are a dead end? You have to validate them anyway so traditional auth is the fallback.

Re: Stop Using JWTs

#146

Earlier quoted context omitted.

I don't recommend PASETO either.

What do you recommend then? What technology has been designed, completed, then used for years without any updates or problems?

https://fly.io/blog/api-tokens-a-tedious-survey/

tl;dr: most of the time you should use opaque random strings.

Re: Stop Using JWTs

#148
JWT is secure.

I just noticed that after JWT was created, people would just slap on JWT like an end-all because JWT sounded secure and they thought it was all that they needed to do.

That’s my only “problem” with JWT but to be honest, people will build insecure systems anyway.

Re: Stop Using JWTs

#149

Earlier quoted context omitted.

You should not be using them for user contexts at all. The cookie should be the session token and the sessions should be stored on the server side where you can simply delete them and the user's login becomes invalid. Using JWTs for this use case is just plain wrong.

I disagree with you and the article on this... I thought that was pretty clear. You can use a revocation list with JWT if necessary, and if your JWTs never last more than 15m you'll be fine.. and if your security window is tighter than that, you probably have bigger issues to deal with.

I think you can use a JWT just fine to introduce a new user into a system but once authenticated just set a classic session cookie with an expiration. I get when you can't for like an API and sure that's where JWTs are best. But a regular website? Not the biggest fan.

Re: Stop Using JWTs

#150

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…

Stateless JWT revocation: https://blog.nellcorp.com/new-aproach-to-jwt-revocation/

Wouldn’t it be simpler to use a session token? This complex machinery does nothing but look fancy.

The application secret is redundant if the per-user secret is used.

Also I’m inferring from the article that the author is using symmetric keys (HS256) for their JWTs. In what world can you securely distribute symmetric keys but can’t use an opaque session token?

Post reply on HN