JWTs suck (for web auth and basically everything else)
speakerdeck.com
speakerdeck.com
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.)
This talk isn't approved by my company.
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
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.
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.
A lot of companies aim to be acquired into becoming features.
I have separate content which addresses these topics in more depth.
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.
Benefit: retain horizontal scaling capabilities, don't have to use local storage.
- 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.
Okay, JWT may not be good at this, let give one point to session cookie.