
JWTs suck (for web auth and basically everything else) - kylequest
https://speakerdeck.com/rdegges/jwts-suck
======
theogravity
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](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.)

~~~
rvz
> 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](https://github.com/fernet/spec)

[1] - [https://paseto.io](https://paseto.io)

[2] - [https://branca.io](https://branca.io)

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

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

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

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

~~~
drspacemonkey
Thanks, I look forward to reading it!

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

------
Can_Not
"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?

------
alephnan
False dilemma. Why not JWT inside a session cookie?

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

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

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

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

------
envolt
I lost is after the score of 0-5.

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

------
daveslash
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](https://news.ycombinator.com/item?id=17877332)

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

