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

271–280 of 335 posts

Re: Stop Using JWTs

#271

Post by gwbas1c »

I once got the heebie-jeebies about an API and on instinct ended up protecting an application from the "macOS Keychain Access Control List (ACL) Zero-Day vulnerability".

This article just sounds like heebie-jeebies, at best it's someone saying something about JWT doesn't smell right (because it can be used incorrectly,) at worst it's a pissing match / religious war.

This article would be more credible if it had a tangible explanation of a real exploit.

(BTW: I don't understand how cookies are inherently "better" or "worse." They can be sniffed and replayed too.)

Re: Stop Using JWTs

#273

Post by Demiurge »

> You must have some state to handle tokens securely, and if you must have a data store, it's better to just store all the data.

This is quite a loaded statement. Why is it better to store all the data? What if you have a CDN layer that only needs to do routing based on authentication or scope, or other token encoded data?

Re: Stop Using JWTs

#274

Post by tptacek »

ForHackernews wrote: post #227
tptacek wrote: post #146

Earlier quoted context omitted.

https://fly.io/blog/api-tokens-a-tedious-survey/ tl;dr: most of the time you should use opaque random strings.

API tokens are a very small narrow part of the authorization universe. Having a shared secret relies on a trust relationship between the resource server and the identity provider that does not exist between, say, my SaaS backend and Google or Meta's login system.

https://www.latacora.com/blog/2018/06/12/inter-service-authe...

Re: Stop Using JWTs

#275

Post by Aldipower »

jongjong wrote: post #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 b…

Thank you. If done right, JWTs simplify quite some things.

Re: Stop Using JWTs

#276

Post by unscaled »

ForHackernews wrote: post #247
unscaled wrote: post #228

Earlier quoted context omitted.

PASETO and TLS 1.3 were also written by humans. TLS libraries (which are several orders of magnitude more complicated than JWT libraries) are also written by humans. If you passionately care about security and misuse-resistance you CAN write a spec that will lead to fewer implementation issues.

You must be young if you're pointing to TLS libraries as an example of doing it right and not getting into trouble with insecure implementations and downgrade attacks. https://wiki.freebsd.org/LibreSSL

I wish I was young. Did I explicitly said TLS __1.3__ or did I not?

A lot of effort was put into making TLS 1.3 a stronger, less agile and more misuse-resistant standard than its previous iterations. And that effort worked.

Re: Stop Using JWTs

#277

Post by unscaled »

ForHackernews wrote: post #250
unscaled wrote: post #231

Earlier quoted context omitted.

The OP was talking about sessions (which include session cookies and API tokens). I'd argue these use cases are far more common for the average programmer than tokens and signatures that are used for federation, but I'll bite the bullet here: JWT is a serviceable solution for service trust and federation. This use case often just requires a very-short-term token, so lack of revocation support is not an issue. Replay…

> If you do use the authorization code flow securely (on the server side, with a strong client secret and proper CSRF protection) This restriction precludes all desktop clients, mobile clients, and webapp clients -- any place where you can't trust the client code to protect a secret. I don't exactly disagree with you: Security becomes much easier once you rule out handling all the hard edge cases.

PKCE, OAuth 2.0 for Native Apps and the Device Code flow are a thing. In practice all of these clients work so well with OAuth 2.0, that the implicit and resource owner password credential grants have been removed from OAuth 2.1 and are the latest OAuth 2.0 BCP forbids the password grant and strongly recommends against the implicit grant.

Re: Stop Using JWTs

#278

Post by ForHackernews »

unscaled wrote: post #277
ForHackernews wrote: post #250

Earlier quoted context omitted.

> If you do use the authorization code flow securely (on the server side, with a strong client secret and proper CSRF protection) This restriction precludes all desktop clients, mobile clients, and webapp clients -- any place where you can't trust the client code to protect a secret. I don't exactly disagree with you: Security becomes much easier once you rule out handling all the hard edge cases.

PKCE, OAuth 2.0 for Native Apps and the Device Code flow are a thing. In practice all of these clients work so well with OAuth 2.0, that the implicit and resource owner password credential grants have been removed from OAuth 2.1 and are the latest OAuth 2.0 BCP forbids the password grant and strongly recommends against the implicit grant.

... so, then, there is a need for something other than a shared opaque random string API key?

I feel like I'm being argued in a circle by a series of strawmen.

Re: Stop Using JWTs

#279

Post by smallerize »

malfist wrote: post #158
saganus wrote: post #112

Earlier quoted context omitted.

I am still waiting for Macaroons to be used widely. I think they are a fantastic invention. It seems they were not of very much use in the past, but with the agentic-everything now, I see this as a great way of delegating permissions to subagents, third-party agents, etc. Working on something along these lines but unfortunately I cannot dedicate as much time as I'd like. Still, if anyone is reading, give Macaroons a…

I like the raspberry ones. Or lemon is also good

Are you thinking of macarons? Macaroons are coconut.

Re: Stop Using JWTs

#280

Post by jollyllama »

joshmarlow wrote: post #57
vidarh wrote: post #46

Earlier quoted context omitted.

The moment you have to look up the user object, you've lost the primary advantage of JWT, and might as well ditch it.

It definitely violates DRY but if you keep passing the JWT down the call chain, you can do redundant permission checking in your business layer. Now the reasonable response to the above is that this should be happening in a dedicated authn/z concern - and that is correct! But when paranoia is called for, it's not unreasonable to have redundant checks in logic where authz is critical.

> It definitely violates DRY

DRY conventionally refers to repeated sections of code, not redundant communications.

Post reply on HN