Stop Using JWTs • Hacker News Board

Re: Stop Using JWTs

#331

Post by unscaled » Sun, Jun 21, 2026, 1:14 PM UTC

ForHackernews wrote: post #278

unscaled wrote: post #277

Earlier quoted context omitted.

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.

For what? For just authenticating a client application to a server without getting access to any user data? By all means. You usually don't need the client credentials in OAuth 2.0 if you don't want to use it.

But if you want access to user information, you can't just give access to an app that has a shared secret key to a all user data for every single users in the planet. You need to authenticate the user somehow, and sharing the user's password directly with the app is not a good idea for many reasons.

Even if you trust the app to be "written without any bugs", the moment you allow the password grant in OAuth, your service cannot use CAPTCHA, MFA or Passkeys efficiently. The password grant does not allow any of these, so this app that you've let through becomes the weakest link for all cybercrime groups that want to attack your service.

Re: Stop Using JWTs

#332

Post by robertlagrant » Wed, Jun 24, 2026, 1:23 PM UTC

inigyou wrote: post #262

robertlagrant wrote: post #241

Earlier quoted context omitted.

You could have a SQL library that defaults to inserting "OR 1=1" to every update query, which the SQL standard allows. I would blame the library.

The SQL library is meant to run the query you give it.

But then "meant to" is doing the heavy lifting here. You could (and should) say that a JWT library is meant to default to secure.

Re: Stop Using JWTs

#333

Post by jkrejcha » Thu, Jun 25, 2026, 9:10 AM UTC

szmarczak wrote: post #330

jkrejcha wrote: post #328

Earlier quoted context omitted.

> True. However it's not impossible to mitigate that: https://news.ycombinator.com/item?id=48563286 It's not a perfect mitigation for session stealing, isn't available in all cases, requires custom code to implement, and also can in some cases completely break sessions (unless they have another place where it's stored) > It's a separate attack vector. It's easily mitigated by having a one week back-off before upgradi…

> isn't available in all cases Which ones? Websites that ship no JavaScript? All browsers support this. > can in some cases completely break sessions Or you can just remove local storage from window and have it just for yourself, which seems what Discord is doing as well. Attackers cannot use local storage because there is no local storage on the window object. > A separate attack vector for the same problem It's not…

In the Discord case they can just call the `getToken()` function. It's not on `window`, but it's trivial to find.

The mitigation is rough on systems where SIGKILL happens early and often. Presumably this is why Discord doesn't do this on mobile. You switching out of the app has a much higher likelihood of that happening than on other platforms. You can't rely on onunload ever getting a chance to run

This also has barely anything to do with local storage, you could do the same for cookies. But with cookies, the browser blocks JS from getting your tokens at all if you use HttpOnly and don't leak it in responses or whatnot, so you don't need to (though you certainly can delete window.cookies if you want as well)

Re: Stop Using JWTs

#334

Post by jkrejcha » Thu, Jun 25, 2026, 9:11 AM UTC

szmarczak wrote: post #325

jkrejcha wrote: post #318

Earlier quoted context omitted.

> First time I'm hearing that frameworks require disabling HttpOnly. They effectively do in the case where you're using local storage because they need to grab the session token from somewhere. The thing about HttpOnly is that JS code never even gets to see the session token. Which is a mitigation for a whole class of vulnerabilities. > ...CSRF You have to mitigate CSRF server-side (with a CSRF token, checking the Se…

> You have to mitigate CSRF server-side (with a CSRF token > when you're using tokens in JavaScript then you don't have to worry because you already have your CSRF token No reason to have a dedicated CSRF token because your local storage token already works as a CSRF token.

It simply doesn't mitigate CSRF by itself

Re: Stop Using JWTs

#335

Post by doc_ick » Tue, Jun 30, 2026, 2:06 PM UTC

tptacek wrote: post #274

ForHackernews wrote: post #227

Earlier quoted context omitted.

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

Archived from 2018, it’d be more relevant to bring up a recipe about Oreo pie.