3 ms·

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 / conten

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

rdegges 7y ago
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.
rvz 7y ago
> 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 7y ago
  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.
kylequest 7y ago
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-token-libraries https://auth0.com/blog/critical-vulnerabilities-in-json-web-...

rdegges 7y ago

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.

rvz 7y ago

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

kylequest 7y ago

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-token-libraries https://auth0.com/blog/critical-vulnerabilities-in-json-web-...