5 ms·

I keep hearing this. Is there a good writeup available?

tstieff 8y ago
The parent comment isn't very helpful, but from what I understand people dislike JWTs because it makes it hard to invalidate a session without some sort of work-around. For example, you can use 2 tokens, one short lived, and one long lived to get around the invalidation problem, but then you will need to occasionally validate that both tokens are still valid, and that state needs to be stored, and now you're storing some state, which is semi-contradictory to the purpose of a stateless-token. Here's a more detailed write-up from another poster -- https://news.ycombinator.com/item?id=12332119 https://news.ycombinator.com/item?id=12332119
- jon-wood 8y ago
  At work we use JWT strictly within our own infrastructure, and opaque tokens for requests coming into our API gateway. This gives us a single point to check tokens are still valid, after which a JWT gets passed back to the backing service. The actual service internally can trust that the token it received is still good to use, in many cases not needing to do any further queries to get user details as their encoded in the token.
- pluma 8y ago
  The way I understand it the only sane use for JWTs is for short-lived delegation of authorisation. E.g. a user wants to talk to service A but access to that service requires certain privileges. Instead of authenticating with service A, the user authenticates with service B (e.g. using a long-lived conventional session mechanism that requires DB lookup), which issues a token the user can then pass to service B (which trusts service A the info is valid and needs no lookup to process the token). JWT standardises a format for that token. Most uses of JWT in the wild however seem to be for authenticating the user of a (web) app with the backend of that same app, so the token is passed from the backend to itself (via the user). This use case is better suited for conventional session tokens.
- jayd16 8y ago
  Isn't that basically oauth?
  - StevePerkins 8y ago
    Yes. In a web setting (the most common use case for JWT), they are typically issued during an oauth dance.
lkschubert8 8y ago
It's a combination of the other comments response about having to still manage state for invalidation and the issue with the none algorithm. JWTs specify the algorithm their signature was encoded with in the alg field of the header. There was a decent portion of JWT libraries that by default honored the alg : none. This would allow the algorithm field to be changed to none even though the JWT had a signature and the libraries would successfully validate the JWT.
danesparza 8y ago
On using JWT's for sessions (which I think most folks assume would be a primary use case) I found this: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/ http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo... Also: it's very easy to abuse JWT tokens by storing them inappropriately... https://stackoverflow.com/a/27301616/19020 https://stackoverflow.com/a/27301616/19020
m3nu 8y ago
JWTs can be read by every script you add to your site, making XSS attacks easier. A cookie with the HttpOnly flag prevents this. I also found cookies easier to use, since the browser handles them and you don't need to attach headers to each request. Any other important concerns or which way is recommended currently?
- deathanatos 8y ago
  > JWTs can be read by every script you add to your site, making XSS attacks easier. A cookie with the HttpOnly flag prevents this. You're confusing JWTs (a standardized token / means of representing claims) and JavaScript localStorage (a storage which can be read by scripts, partitioned by origin). The two are completely orthogonal; you could store a JWT in a cookie, if you wanted to. > JWTs [… make] XSS attacks easier. I also found cookies easier to use, since the browser handles them and you don't need to attach headers to each request. The browser handling them automatically means you need to think about CSRF, which I think largely negates the benefits. If your site is vulnerable to XSS, a cookie won't save you; the XSS attacker just makes the necessary authenticated request using an AJAX. My current favorite writeup on this is https://portswigger.net/blog/web-storage-the-lesser-evil-for-session-tokens https://portswigger.net/blog/web-storage-the-lesser-evil-for...
  - beardedwizard 8y ago
    CSRF is mitigated by using the samesite cookie flag. XSS is mitigated by httponly, except where XSS makes legitimate requests to domains specified by the cookie. This article describes some of the most vulnerable ways to use a JWT in 2019, but please let's stop talking about none algorithms.
    - fenwick67 8y ago
      samesite doesn't appear to work in Safari, IE or Edge sadly. EDIT: apparently it's a bit more complicated than that: IE11 on windows 7 doesn't support it, and Safari < iOS12 doesn't support it. Still seems like a significant-enough chunk that you can't rely on it. https://caniuse.com/#search=samesite https://caniuse.com/#search=samesite
CiPHPerCoder 8y ago
Blog post: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... DEFCON CPV talk: https://paragonie.com/files/talks/NoWayJoseCPV2018.pdf https://paragonie.com/files/talks/NoWayJoseCPV2018.pdf + https://youtu.be/RijGNytjbOI https://youtu.be/RijGNytjbOI Alternative design that isn't radioactive: https://paseto.io https://paseto.io Apologies if this wasn't more readily available or commonly known. I'm worse at marketing than I am at engineering.
- tenaciousDaniel 8y ago
  [bookmarks] Thanks a lot! This is exactly what I needed.
StevePerkins 8y ago
Most of the "discussion" on this topic spins out of this blog post: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba.... Which unfortunately is: 1. A bit unnecessarily abrasive and hysterical in its style, and 2. Comes from a PHP consulting firm, promoting their own alternative proposal (which hardly anyone else seems to discuss or use). So I think #1 above is really about drawing eyeballs and selling services, more so than providing clear information for a newcomer to follow. JWT does have its issues, though. They basically break down into two points: 1. Because of its distributed nature, there's no built-in way to invalidate a JWT prior to its natural expiration. You have to roll your own approach for this, typically some sort of whitelist or blacklist mechanism (which defeats some of JWT's advantages). 2. By default, the spec and its major library implementations allow JWT's to specify a number of different signing algorithms (including "None"!). This is dangerously nonobvious for newbies. Best practice is to configure your code to only allow a limited number of algorithms (i.e. one).
- CiPHPerCoder 8y ago
  > Comes from a PHP consulting firm, promoting their own alternative proposal (which hardly anyone else seems to discuss or use). So I think #1 above is really about drawing eyeballs and selling services, more so than providing clear information for a newcomer to follow. There was a recent (November 2018) talk at London Gophers about JWT Alternatives (slides here: https://speakerdeck.com/hako/exploring-alternatives-to-json-web-tokens-jwt https://speakerdeck.com/hako/exploring-alternatives-to-json-...). Keep in mind that PASETO didn't exist until the middle of 2018, so the main reason "hardly anyone else" seems to use it is precisely because it takes time for standards to be adopted. If you take a look at https://paseto.io https://paseto.io, you'll see that there are implementations of PASETO (our proposed alternative) in multiple programming languages by other companies and individuals. All of these implementations are open source and under very permissive licenses (MIT or ISC). Additionally, a great deal of time and effort went into the PASETO documentation, so that developers can understand not only how to implement it themselves, but also why it was designed the way it is. https://github.com/paragonie/paseto/tree/master/docs https://github.com/paragonie/paseto/tree/master/docs Given all of the above, is it really fair to write PASETO off as an attempt to sell services? Claiming that the original article is meant to sell services doesn't make sense either: If developers keep using unsafe tools, they will continue to be less secure and I'll have an easier time selling "make your products/services more secure" services to developers. The best thing to do, to meet such an incentive, is to say nothing publicly and let the easy money keep rolling in. So one of two things is happening: 1. You don't correctly understand our intentions. 2. We're really bad at understanding our own incentives, and it's a miracle we've been in business for 4 years.
netvarun 8y ago
tptacek posted some good commentary on this a while back - https://news.ycombinator.com/item?id=14292223 https://news.ycombinator.com/item?id=14292223
- dkarl 8y ago
  This is the best explanation I've seen. I think many commenters mean to say something similar but don't give enough context. Here's my phrasing of what I take away from tptacek's comment: JWT is designed to be customized for a variety of use cases, which means programmers using JWT are rolling their own security scheme, including choosing cryptography from a practically unrestricted field of options. This is known to be a recipe for disaster. A good standard should provide an expert-validated scheme for a specific use case that gives end programmers assurance that if they comply with the standard, the scheme will fulfill its intended use case. This means standardizing separate use cases separately; therefore, JWT is at best a technology that experts could use (but probably wouldn't) to devise specific standard solutions for specific use cases which would then be appropriate for end programmers to use.

The parent comment isn't very helpful, but from what I understand people dislike JWTs because it makes it hard to invalidate a session without some sort of work-around. For example, you can use 2 tokens, one short lived, and one long lived to get around the invalidation problem, but then you will need to occasionally validate that both tokens are still valid, and that state needs to be stored, and now you're storing some state, which is semi-contradictory to the purpose of a stateless-token. Here's a more detailed write-up from another poster -- https://news.ycombinator.com/item?id=12332119 https://news.ycombinator.com/item?id=12332119

jon-wood 8y ago
At work we use JWT strictly within our own infrastructure, and opaque tokens for requests coming into our API gateway. This gives us a single point to check tokens are still valid, after which a JWT gets passed back to the backing service. The actual service internally can trust that the token it received is still good to use, in many cases not needing to do any further queries to get user details as their encoded in the token.
pluma 8y ago
The way I understand it the only sane use for JWTs is for short-lived delegation of authorisation. E.g. a user wants to talk to service A but access to that service requires certain privileges. Instead of authenticating with service A, the user authenticates with service B (e.g. using a long-lived conventional session mechanism that requires DB lookup), which issues a token the user can then pass to service B (which trusts service A the info is valid and needs no lookup to process the token). JWT standardises a format for that token. Most uses of JWT in the wild however seem to be for authenticating the user of a (web) app with the backend of that same app, so the token is passed from the backend to itself (via the user). This use case is better suited for conventional session tokens.
jayd16 8y ago
Isn't that basically oauth?
- StevePerkins 8y ago
  Yes. In a web setting (the most common use case for JWT), they are typically issued during an oauth dance.

lkschubert8 8y ago

It's a combination of the other comments response about having to still manage state for invalidation and the issue with the none algorithm. JWTs specify the algorithm their signature was encoded with in the alg field of the header. There was a decent portion of JWT libraries that by default honored the alg : none. This would allow the algorithm field to be changed to none even though the JWT had a signature and the libraries would successfully validate the JWT.

danesparza 8y ago

On using JWT's for sessions (which I think most folks assume would be a primary use case) I found this: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/ http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo... Also: it's very easy to abuse JWT tokens by storing them inappropriately... https://stackoverflow.com/a/27301616/19020 https://stackoverflow.com/a/27301616/19020

m3nu 8y ago

JWTs can be read by every script you add to your site, making XSS attacks easier. A cookie with the HttpOnly flag prevents this. I also found cookies easier to use, since the browser handles them and you don't need to attach headers to each request. Any other important concerns or which way is recommended currently?

deathanatos 8y ago
> JWTs can be read by every script you add to your site, making XSS attacks easier. A cookie with the HttpOnly flag prevents this. You're confusing JWTs (a standardized token / means of representing claims) and JavaScript localStorage (a storage which can be read by scripts, partitioned by origin). The two are completely orthogonal; you could store a JWT in a cookie, if you wanted to. > JWTs [… make] XSS attacks easier. I also found cookies easier to use, since the browser handles them and you don't need to attach headers to each request. The browser handling them automatically means you need to think about CSRF, which I think largely negates the benefits. If your site is vulnerable to XSS, a cookie won't save you; the XSS attacker just makes the necessary authenticated request using an AJAX. My current favorite writeup on this is https://portswigger.net/blog/web-storage-the-lesser-evil-for-session-tokens https://portswigger.net/blog/web-storage-the-lesser-evil-for...
- beardedwizard 8y ago
  CSRF is mitigated by using the samesite cookie flag. XSS is mitigated by httponly, except where XSS makes legitimate requests to domains specified by the cookie. This article describes some of the most vulnerable ways to use a JWT in 2019, but please let's stop talking about none algorithms.
  - fenwick67 8y ago
    samesite doesn't appear to work in Safari, IE or Edge sadly. EDIT: apparently it's a bit more complicated than that: IE11 on windows 7 doesn't support it, and Safari < iOS12 doesn't support it. Still seems like a significant-enough chunk that you can't rely on it. https://caniuse.com/#search=samesite https://caniuse.com/#search=samesite

CiPHPerCoder 8y ago

Blog post: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... DEFCON CPV talk: https://paragonie.com/files/talks/NoWayJoseCPV2018.pdf https://paragonie.com/files/talks/NoWayJoseCPV2018.pdf + https://youtu.be/RijGNytjbOI https://youtu.be/RijGNytjbOI Alternative design that isn't radioactive: https://paseto.io https://paseto.io Apologies if this wasn't more readily available or commonly known. I'm worse at marketing than I am at engineering.

tenaciousDaniel 8y ago
[bookmarks] Thanks a lot! This is exactly what I needed.

StevePerkins 8y ago

Most of the "discussion" on this topic spins out of this blog post: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba.... Which unfortunately is: 1. A bit unnecessarily abrasive and hysterical in its style, and 2. Comes from a PHP consulting firm, promoting their own alternative proposal (which hardly anyone else seems to discuss or use). So I think #1 above is really about drawing eyeballs and selling services, more so than providing clear information for a newcomer to follow. JWT does have its issues, though. They basically break down into two points: 1. Because of its distributed nature, there's no built-in way to invalidate a JWT prior to its natural expiration. You have to roll your own approach for this, typically some sort of whitelist or blacklist mechanism (which defeats some of JWT's advantages). 2. By default, the spec and its major library implementations allow JWT's to specify a number of different signing algorithms (including "None"!). This is dangerously nonobvious for newbies. Best practice is to configure your code to only allow a limited number of algorithms (i.e. one).

CiPHPerCoder 8y ago
> Comes from a PHP consulting firm, promoting their own alternative proposal (which hardly anyone else seems to discuss or use). So I think #1 above is really about drawing eyeballs and selling services, more so than providing clear information for a newcomer to follow. There was a recent (November 2018) talk at London Gophers about JWT Alternatives (slides here: https://speakerdeck.com/hako/exploring-alternatives-to-json-web-tokens-jwt https://speakerdeck.com/hako/exploring-alternatives-to-json-...). Keep in mind that PASETO didn't exist until the middle of 2018, so the main reason "hardly anyone else" seems to use it is precisely because it takes time for standards to be adopted. If you take a look at https://paseto.io https://paseto.io, you'll see that there are implementations of PASETO (our proposed alternative) in multiple programming languages by other companies and individuals. All of these implementations are open source and under very permissive licenses (MIT or ISC). Additionally, a great deal of time and effort went into the PASETO documentation, so that developers can understand not only how to implement it themselves, but also why it was designed the way it is. https://github.com/paragonie/paseto/tree/master/docs https://github.com/paragonie/paseto/tree/master/docs Given all of the above, is it really fair to write PASETO off as an attempt to sell services? Claiming that the original article is meant to sell services doesn't make sense either: If developers keep using unsafe tools, they will continue to be less secure and I'll have an easier time selling "make your products/services more secure" services to developers. The best thing to do, to meet such an incentive, is to say nothing publicly and let the easy money keep rolling in. So one of two things is happening: 1. You don't correctly understand our intentions. 2. We're really bad at understanding our own incentives, and it's a miracle we've been in business for 4 years.

netvarun 8y ago

tptacek posted some good commentary on this a while back - https://news.ycombinator.com/item?id=14292223 https://news.ycombinator.com/item?id=14292223

dkarl 8y ago
This is the best explanation I've seen. I think many commenters mean to say something similar but don't give enough context. Here's my phrasing of what I take away from tptacek's comment: JWT is designed to be customized for a variety of use cases, which means programmers using JWT are rolling their own security scheme, including choosing cryptography from a practically unrestricted field of options. This is known to be a recipe for disaster. A good standard should provide an expert-validated scheme for a specific use case that gives end programmers assurance that if they comply with the standard, the scheme will fulfill its intended use case. This means standardizing separate use cases separately; therefore, JWT is at best a technology that experts could use (but probably wouldn't) to devise specific standard solutions for specific use cases which would then be appropriate for end programmers to use.