Hacker News new | past | comments | ask | show | jobs | submit login

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

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