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

151–160 of 335 posts

Re: Stop Using JWTs

#151

Post by encodedrose »

himata4113 wrote: post #99
iririririr wrote: post #98

Earlier quoted context omitted.

irrevocable* cache

I've adapted dynamic public-key hotswapping whenever there is a need to revoke tokens as it would simply force all tokens to go to /refresh endpoint instead of the standard 5m cache. Never had to use it though. I've experimented deriving the public key from the uuid so I could broadcast that "keys with this id and this revision should no longer be accepted and should be refreshed", but as I said never ran into a situ…

This is an interesting approach especially if you factor in that re-minting a key is usually a lightweight task compared to what most API calls have to interact with.

If the re-minting happens transparently with a user interaction then you spread out some of the request velocity that can come with that (if you're operating at a large enough scale for it to matter for this to be a concern).

Re: Stop Using JWTs

#153

Post by jzelinskie »

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…

Lots of very bad uses for JWTs for service-to-service communication, too. There are often way more standard/foolproof alternatives than how lots of people use JWTs on the backend.

I feel like discussions like these usually will surface PASETO/Macaroons/Thin Mints as the fix without acknowledging that the complexity of distributed token passing with arbitrary attenuation isn't a fit for most use cases.

That all being said, sometimes JWT is the right solution for the job! It's the core skill of software engineering to be able to take in all the arguments and tradeoffs and make the right choice for your scenario.

Full disclaimer: Take what I say with a grain of salt because I build a project (SpiceDB) that advocates for a more centralized approach for one of the backend JWT use cases: fine-grained authorization.

Re: Stop Using JWTs

#154

Post by asattarmd »

JWTs are secure in the sense that they are tamper-proof. And that's all you need for a session token (plus the revocation list). There's nothing inherently insecure about JWTs.

Re: Stop Using JWTs

#155

Post by green_wheel »

> The JWT specification is specifically designed only for very short-live tokens (~5 minute or less). Sessions need to have longer lifespans than that.

Citation needed. Where does it say this?

Re: Stop Using JWTs

#156

Post by Natfan »

hparadiz wrote: post #22
jotato wrote: post #18

Earlier quoted context omitted.

> "You cannot invalidate individual JWT tokens". Which every time I've implemented, the general guideline is to check for invalidated nonces somewhere. Which resolves that random blog posts second point too. 100% agree. This is common sense to me and I'm always surprised to re-learn people don't do this

Not checking the signature on every single JWT is the same as storing a password in plain text.

worse, it's storing identities in an editable format that any attacker can use to impersonate any user, no?

Re: Stop Using JWTs

#157

Post by hparadiz »

Natfan wrote: post #156
hparadiz wrote: post #22

Earlier quoted context omitted.

Not checking the signature on every single JWT is the same as storing a password in plain text.

worse, it's storing identities in an editable format that any attacker can use to impersonate any user, no?

Even worse than both of those scenarios. If you don't check the signature anyone can simply write whatever they want in the payload string. The signature is always generated by combining the payload with a private key. Then the receiver uses the public key to verify the signature. If you don't do that the payload can be modified to be anything. Storage not required by the attacker.

It's like prompting for a password but accepting any password as valid.

Re: Stop Using JWTs

#158

Post by malfist »

saganus wrote: post #112
nine_k wrote: post #19

Earlier quoted context omitted.

> 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! One reason could be the size. A revocation list only needs to keep session IDs of recently logged-out sessions, for which the token's TTL hasn't yet expired. It may be a much smaller list than a list of every active session. Also, a JWT (or a Macaroon, etc) can store…

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

Re: Stop Using JWTs

#159

Post by tptacek »

saganus wrote: post #112
nine_k wrote: post #19

Earlier quoted context omitted.

> 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! One reason could be the size. A revocation list only needs to keep session IDs of recently logged-out sessions, for which the token's TTL hasn't yet expired. It may be a much smaller list than a list of every active session. Also, a JWT (or a Macaroon, etc) can store…

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…

We have what I believe to be one of the world's largest deployments of Macaroons. They're a mixed bag, though I think they're a lot more interesting in a world where agents do most of the fiddly work.

https://fly.io/blog/operationalizing-macaroons/

Re: Stop Using JWTs

#160

Post by tptacek »

jiveturkey wrote: post #126
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…

JWTs can do that (delegate) and such capability is already well defined.

Most token formats delegate. Macaroons support attenuation, confinement, and embedded third-party claims, none of which are JWT capabilities.
Post reply on HN