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

281–290 of 335 posts

Re: Stop Using JWTs

#281

Post by jongjong »

nine_k wrote: post #19
RagingCactus wrote: post #16

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…

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

Another point is that managing session data on the server-side is a pain... If your app server goes down, stale session data would be left behind in your session store; it can easily become orphaned... So you need to set an expiry on it to ensure that it will be cleaned up no matter what... But you need to keep extending the expiry while the user is still online. God forbid you create the session data before you set the expiry on it and the operation that sets the expiry fails (e.g. server crashes at the precise moment or some error occurs which causes it to be skipped)... In practice, it's hard to avoid stale/orphaned session data.

And yes, you need to store and manage more data and your session store is an additional Single Point of Failure... With JWT the revocation list is an optional... Your system can keep running without it; it just won't be able to ban users. It's a cleaner separation of concerns without SPoF.

JWTs have so many benefits over session IDs, I could write a book about all the benefits. Sure, there are some tradeoffs but the negatives are typically pretty minor or hand-wavy.

Re: Stop Using JWTs

#282

Post by carter2099 »

owaislone wrote: post #217

JWTs are awesome but they are are being overused by people. People use them in web, on mobile and everywhere in between. Places where cookie or bearer token auth has already solved the problems. JWTs strength is that it can be verified independently without real-time coordination between services. So a service can issue a JWT with auth scopes to a user. The user can take the JWT to any other service and if that servi…

> Servers must ... make DB calls to verify the user is still active

I'm not being facetious, genuinely asking - is this a big deal? Should be a pretty cheap query, and with pooled connections, hardly any overhead.

Re: Stop Using JWTs

#283

Post by Manouchehri »

Hear me out: use JWTs as the cookie session value.

- Use ES256

- Always set the JTI to be completely random

- Set iat (issued at time) and exp (expiration time)

- Set iss (issuer) and aud (audience) to match your application

- Set sub (subject) to match whatever unique identifier you use for users

Store the hash of the JWT in your database with a lazy cleanup hook on the expiration time.

Now, you can use this JWT for a cheap WAF at the edge!

Token expired already? No need to query the database, reject.

Audience doesn't match the requested URL? No need to query the database, reject.

Signature doesn't match your public key? No need to query the database, reject.

Everything passes? Query the database for the token hash.

Token hash not in the database? Add the token hash to the WAF's cache (with lazy cleanup hook on the expiration time).

Everything passes but token hash in the WAF cache of rejects? No need to query the database, reject.

etc

See the benefit? It's defense in depth. If you screw this up, all you lose is the WAF layer.

Re: Stop Using JWTs

#284

Post by sauercrowd »

The short term tokens section is weird.

> If you do need a short-lived, signed token for something, there is a better spec called PASETO which is designed to be secure

Suggesting to non security people (like myself) something for auth that isn't a mainstream idea seems like a bad idea? Not to mention that it doesn't refer any reasons why it's better

Re: Stop Using JWTs

#285

Post by hparadiz »

locknitpicker wrote: post #260
hatefulheart wrote: post #244

Earlier quoted context omitted.

Yes we have heard this before, React is only 30kb! But that misses the enormous amount of infra you need to even just do a basic fetch. (Read the post by the React Query author on whether you need React Query or not) Likewise with JWTs for sessions you need to handle cache invalidation, revocation lists, key rotation, the list of difficult comp sci problems really does go on! The same issue as always plaguing the fro…

> Yes we have heard this before, React is only 30kb! Not quite. You might be surprised to know, but the whole JOSE standard, and JWT in particular, specify a very limited set of fields. Whenever anyone starts requiring more than that, the responsibilities start to be offloaded to the likes of OpenID Connect.

This is actually really funny because I recently had this problem having to authenticate an internal repo with an OIDC but the script had to run so early in the bootstrap processes that the python google sdk is not yet installed so I had to manually install the SDK before apt is available by pulling it down manually to bootstrap the chicken or the egg problem. My initial implementation was using curl but folks insisted (rightly) on using the official SDK. I'm sure it's a lot more than 30kb though not during runtime per say.

Re: Stop Using JWTs

#286

Post by andai »

ForHackernews wrote: post #229
andai wrote: post #132

Earlier quoted context omitted.

I read an article about business which had this classification, "Would be weird if it worked", "Might work", and "Would be weird if it didn't work" and argued that you want to be in the last category. In engineering we aspire to a slightly stronger standard: "I made it physically impossible to fuck this up."

And yet https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse...

Yeah I don't think they were aspiring to that

Re: Stop Using JWTs

#287

Post by szmarczak »

adithyassekhar wrote: post #121
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…

> Discord removes it on page load and restores it when the tab is closed. How does this work? You have no real control over what the browser does when it closes a tab.

Except you do. https://developer.mozilla.org/en-US/docs/Web/API/Window/unlo...

What happens if you lose power? You're logged out because it didn't save the token back. Verified this by pausing JS execution and killing Firefox. (the local storage key is "token")

Re: Stop Using JWTs

#288

Post by szmarczak »

efilife wrote: post #182
adithyassekhar wrote: post #121

Earlier quoted context omitted.

> Discord removes it on page load and restores it when the tab is closed. How does this work? You have no real control over what the browser does when it closes a tab.

I've always wondered how they do it as well. Second problem - if they remove it from localstorage they still need to hold them somewhere. So are they moved to a simple variable then? It's just as accessible as localStorage. Maybe it's randomized every load?

> I've always wondered how they do it as well.

See https://news.ycombinator.com/item?id=48574402

> So are they moved to a simple variable then?

Yup, it has to exist somewhere.

Re: Stop Using JWTs

#289

Post by tasuki »

tptacek wrote: post #261
tasuki wrote: post #255

Earlier quoted context omitted.

It's curious: very few authentication systems I ever implemented needed some way to invalidate sessions.

You either reissue tokens constantly, every couple minutes or so, or you have to reliably invalidate.

Maybe you do. Why would I have to do that?

Re: Stop Using JWTs

#290

Post by jbosh »

tasuki wrote: post #188
ApolloFortyNine wrote: post #8

This links to some other blog post for the bulk of it's 'why', and that blog post mostly seems to be annoyed about "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. >The JWT specification itself is not trusted by security experts. This feels like it needs more evi…

Also many situations just don't require a "Logout" button and hence don't require a revoked list. On a linked page, there's also this: > Any JavaScript code on your page can access local storage: it has no data protection whatsoever. This is the big one for security reasons (as well as my number one pet peeve in recent years). This is a weak argument. You know, just don't put "any javascript code" on your webpage? Li…

The author made a good point here about running trackers and ad ops (think Google analytics or ad words). I'd guess if you don't run those, it'd just be supply chain attacks that could exfiltrate secrets.

This seems like one of those scenarios where you make different trade offs depending on your threat model. The author's threat model sounds similar to a news site where they track and advertise so they're forced to run semi-trusted js.

Post reply on HN