Hacker News new | past | comments | ask | show | jobs | submit login
JWTs suck (for web auth and basically everything else) (speakerdeck.com)
48 points by kylequest 60 days ago | hide | past | web | favorite | 22 comments



Note that Auth0 is a competitor of Okta, and Auth0 is all-in on JWT. Searching for anything JWT will most likely end up on an Auth0 site since the docs / content marketing is pretty well-done; they've obviously optimized for SEO. Their docs also cover how not to store a JWT as well.

https://auth0.com/docs/security/store-tokens

The author of the deck is the "Chief Hacker" at Okta.

I would read the deck keeping that bias in mind.

(We recently had to lots of research into a 3rd party IDP to use, and chose Auth0 in the end over Okta.)


> Their docs also cover how not to store a JWT as well.

Well, it tells you something about that JWTs allow more ways to misuse the token spec which already makes it a bad standard. alg = none is still in the standard, no encryption by default and there is no sane cryptographic choice to sign/encrypt the JWT, which allows developers to shoot themselves in the foot as what we have here with using it with sessions.

Fernet [0] was the closest to being a successor of a better standard, but I believe PASETO [1] or even Branca [2] tokens look much more better alternative for JWTs. If not, then the good old session cookie may suffice even.

[0] - https://github.com/fernet/spec

[1] - https://paseto.io

[2] - https://branca.io


I have to agree with you. Without research, JWT is basically a foot-gun. I was aware of these issues from reading like-articles about JWT in the past. We work with a security engineer to try to ensure we're using JWTs appropriately.

One can argue that any generic tool can be used in an insecure fashion - common one is JSON.parse() in Javascript. By default, it's susceptible to prototype pollution. I can guarantee you that most devs will use that call on user input without appropriate sanitization.

Just like how the JWT spec hasn't been updated to disallow a lack of an algorithm, I'm unsure why JS doesn't offer a 'safe' version of the parse in the API.

We only use JWTs where it makes sense. For browser-based access, we personally prefer cookies with opaque ids to represent a session.


I'm the original author. I'll just say that if you watch the talk live, I discuss this and point out that Okta used JWTs as well.

This talk isn't approved by my company.


Speaking of Auth0 and JWT... there was this nice (guest) blog post a while ago where they do cover some of the JWT problems: https://auth0.com/blog/critical-vulnerabilities-in-json-web-...


huh. The author is "chief hacker" @ okta. This deck doesn't inspire confidence in okta. It doesn't make me want to run screaming either, though. Maybe just on the bad side of neutral. As as aside, how is okta (and OneLogin) even a thing? They are features masquerading as a company (phrase I learned on HN recently).

Perhaps, I don't know but perhaps, the interwebs is full of the type of misinformation/myths that the deck is challenging, but the reality (which I would assume a chief hacker, ie principal engineer is very well aware of) is that they are neither worse nor better than a plain cookie. I've no idea why you'd store the jwt in localstorage, again this may be an interwebs thing that doesn't reflect good choices. As a cookie-equivalent, you get, for free, a widely implemented abstraction that you learn once and portably apply everywhere. The complexity problem just isn't there AFAICT, and the choices are there for you. With pure cookies, you have to invent everything yourself.

I find particularly puzzling the claim about revocation. The example (p. 47) is a particularly naive implementation, which would scale equally poorly for homemade session ID or jwt.

Based on this visual deck alone -- I make an allowance for audio providing more detail -- I fail to see a well supported argument.

It reads much more as a soft ad for paseto.


The author kinda lost me halfway through. Was mobile or other non-web API interaction ever addressed in any meaningful way? Specifically, how much it sucks to to allow 3rd parties (or even 1st-party non-web-browser clients) access to your API if authentication is done via session cookies? Cuz that's a pretty significant thing to just gloss over.


Thanks for the comment! I didn't cover that in this talk as it was written for a 1 hour timeslot and already ran long.

I have separate content which addresses these topics in more depth.


Thanks, I look forward to reading it!


OAuth is a pretty popular option for delegation... and JWT isn't really necessary there...


> They are features masquerading as a company (phrase I learned on HN recently).

A lot of companies aim to be acquired into becoming features.


The localStorage vs cookies slide is wrong. localStorage does not open you up to XSS, you can have XSS with cookies as well. What the author probably meant is that cookies marked with `HttpOnly` cannot be exfiltrated via XSS, which is true, but:

1. Preventing exfiltration is not very useful. If you have an XSS, you're already in trouble. Instead of exfiltrating the cookie, the XSS author could send a POST to the endpoint that changes the password, for example.

2. You can also prevent localStorage exfiltration with either CSP's `connect-src` or a service worker, so that's not an advantage for cookies.

For a single page application, I would say that there is zero advantage to using cookies instead of localStorage for most use cases. In fact, it's harmful because now you have to deal with CSRF.


"JWT are more flexible" both points to expiration dates. Both kinda looks the same. No explanation why session cookies got the point. Maybe I don't understand how to use that website on mobile?


False dilemma. Why not JWT inside a session cookie?

Benefit: retain horizontal scaling capabilities, don't have to use local storage.


I'm the original author. There are several reasons:

- The cookie payload if you're using stateless JWTs will often be > 4kb, meaning you can't store the JWT in a cookie. - You get no benefit from doing it this way since it is more complex to use JWTs than plain old session cookies. - You will still need centralization regardless if you want to support token revocation.


To be fair, 90% of the time i see people recommend JWT for auth, it's a session token inside a jwt in a cookie, which then gets decoded and checked against the db in the backend


Using a cookie is not a benefit, it's a downside. You have to deal with CSRFs, which aren't possible with localStorage.


But then you open yourself up to XSS which is a lot harder to defend against.


You don't open yourself up to XSS, see my comment above: https://news.ycombinator.com/item?id=20773188


I lost is after the score of 0-5.

Okay, JWT may not be good at this, let give one point to session cookie.


This looks like an updated version of the the exact same talk from the same author from 2017. Link to 2017 talk below, with HN comments from 2 years ago.

https://news.ycombinator.com/item?id=17877332


Yeah I went through three different authentication implementations and cookie session is for the majority of the use cases. JWT is bad for most cases. If you want to authenticate a user most use cases require storing the cookie in a database so the token isn’t stateless anymore.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: