6 ms·

How the heck did JWT get such a following with issues like these?

intothemild 8y ago
Because front-end engineers always fall for whatever cult is hyped right now. They usually don’t understand the issues around the things they want to build, they do it because it’s cool and new, and don’t stop to ask or research anything.
- ponyous 8y ago
  And backend engineers not researching how to properly implement them and completely missing the point, yet arguing and blaming front end devs for being "useless". /sarcasm On a serious note: JWTs have use cases, but your company is probably not the one. Nice thing about JWT is that there is no need to query the DB every time a request hits a service. JWTs for session should be short lived and refreshed often. In case you need to invalidate it, you invalidate refresh token and window for attack becomes short. It's not perfect but it's certainly not useless and just the hype.
- deleted 8y ago
  [deleted]
rusk 8y ago
Having recently joined a project that uses JWT (I was completely ignorant of it beforehand - cookies all the way), I can say that a key advantage is convenience for developers and testing. Once you have the secret for signing you can pretty much access any of the application without having to jimmy the access-controls. I guess that could be a weakness too, but in my experience in fast moving commercially driven environments with little technical oversight (a lot of the industry these days) developer convenience does seem to drive a lot of design choices ...
- shusson 8y ago
  > JWT (I was completely ignorant of it beforehand - cookies all the way) JWTs can be stored in cookies. So I don't understand why you say this.
  - rusk 8y ago
    Oh I'm not aware of the means of using JWT you describe. I think the context of this article is using JWT exclusively, and by the looks of things plenty of people are doing just that.
    - 0xffff2 8y ago
      The article specifically addresses the confusion that you're exhibiting: >A lot of people mistakenly try to compare "cookies vs. JWT". This comparison makes no sense at all, and it's comparing apples to oranges - cookies are a storage mechanism, whereas JWT tokens are cryptographically signed tokens. There's no such thing as "JWT exclusively". The JWT is just a chunk of data; it has to be stored somewhere, either in a cookie or in local storage.
      - rusk 8y ago
        I’m not too sure what you’re talking about but the article is about this confusion.
deleted 8y ago
[deleted]
tschellenbach 8y ago
The article exaggerates these issues. Also there are easy solutions available for those concerns. It's trivial to store a token version on your user object and invalidate any token that has the wrong version.
- dchest 8y ago
  Then just store session ID there and get rid of JWT.
  - indeyets 8y ago
    There's big difference between fetching session from db and validating id via short local (push distributed) revoke list. Well, that's if project is large enough to saturate storage :)
cryptica 8y ago
This article is propaganda. This is not the first article of its kind; they just keep popping up over and over on HN with the same poor arguments. I usually take the time to write long explanations as to why these points are invalid but I'm tired of arguing with these people. The real reason for these articles I think is that some developers had a very traumatic experience with a poorly implemented JWT authentication system once in their career and now nothing will change their minds about JWTs. Maybe JWTs don't make as much sense for HTTP but for WebSockets they are absolutely crucial. With WebSockets for example, you can push the JWTs to the clients so you can make them with very short expiry: e.g. even 10 minute expiry is possible... Issuing/renewing JWTs with very short expiry helps avoid the need to explicitly invalidate them... If used correctly, JWTs can take a lot of load off from the database. I could go on for a long time about the benefits of JWTs with WebSockets but to summarize the best aspect for me is that you can push them to the client with short expiry and also that you can automatically renew/re-issue them on an interval while the connection is alive... It also works well for dealing with socket reconnects and saves database lookups.
- CiPHPerCoder 8y ago
  > This article is propaganda. Someone else called it FUD, now you're calling it propaganda. I'm seeing a pattern. > This is not the first article of it's kind; they just keep popping up over and over on HN with the same poor arguments. I usually post long explanations as to why these points are invalid but I'm tired of arguing with these people. ...they said, commenting on an Internet board where discussions (a.k.a. arguments) often unfold with these people. Why are these arguments poor? In what sense does "JWT instead of server-side storage" make a better engineering decision? > The real reason for these articles I think is that some developers had a very traumatic experience with poorly implemented JWT authentication system once in their life and now nothing will convince them otherwise. Your ad hominem straw man argument notwithstanding, there are two orthogonal arguments that JWT defenders seem to conflate: 1. Don't misuse JWT in places it wasn't designed for. <- You are here 2. JWT is an error-prone cryptographic design and should be replaced with a better standard. You can agree with one without agreeing with the other. > Maybe JWTs don't make as. much sense for HTTP but for WebSockets they are absolitely crucial. Would PASETO be a better fit than JWT for your envisioned WebSockets use case? https://github.com/paragonie/paseto/tree/master/docs https://github.com/paragonie/paseto/tree/master/docs
jayd16 8y ago
If you don't care about invalidating single user sessions or any of the other downsides, it works pretty well.
giobox 8y ago
JWTs have long been a favourite topic of software engineer bloggers as they do raise a lot of interesting technical questions. Whether we can take this as evidence of a big following in actual production implementations I’m not so sure, but if forced to guess I suspect they are exceedingly rare (compared to stateful systems) outside of programmer side projects. I’ve rarely ever seen stateless auth used on anything serious, as others have noted many times before the issues with invalidating previously issued tokens often removes the “stateless” part, after which you are just as well using more traditional mechanisms.

Because front-end engineers always fall for whatever cult is hyped right now. They usually don’t understand the issues around the things they want to build, they do it because it’s cool and new, and don’t stop to ask or research anything.

ponyous 8y ago
And backend engineers not researching how to properly implement them and completely missing the point, yet arguing and blaming front end devs for being "useless". /sarcasm On a serious note: JWTs have use cases, but your company is probably not the one. Nice thing about JWT is that there is no need to query the DB every time a request hits a service. JWTs for session should be short lived and refreshed often. In case you need to invalidate it, you invalidate refresh token and window for attack becomes short. It's not perfect but it's certainly not useless and just the hype.
deleted 8y ago
[deleted]

rusk 8y ago

Having recently joined a project that uses JWT (I was completely ignorant of it beforehand - cookies all the way), I can say that a key advantage is convenience for developers and testing. Once you have the secret for signing you can pretty much access any of the application without having to jimmy the access-controls. I guess that could be a weakness too, but in my experience in fast moving commercially driven environments with little technical oversight (a lot of the industry these days) developer convenience does seem to drive a lot of design choices ...

shusson 8y ago
> JWT (I was completely ignorant of it beforehand - cookies all the way) JWTs can be stored in cookies. So I don't understand why you say this.
- rusk 8y ago
  Oh I'm not aware of the means of using JWT you describe. I think the context of this article is using JWT exclusively, and by the looks of things plenty of people are doing just that.
  - 0xffff2 8y ago
    The article specifically addresses the confusion that you're exhibiting: >A lot of people mistakenly try to compare "cookies vs. JWT". This comparison makes no sense at all, and it's comparing apples to oranges - cookies are a storage mechanism, whereas JWT tokens are cryptographically signed tokens. There's no such thing as "JWT exclusively". The JWT is just a chunk of data; it has to be stored somewhere, either in a cookie or in local storage.
    - rusk 8y ago
      I’m not too sure what you’re talking about but the article is about this confusion.

deleted 8y ago

[deleted]

tschellenbach 8y ago

The article exaggerates these issues. Also there are easy solutions available for those concerns. It's trivial to store a token version on your user object and invalidate any token that has the wrong version.

dchest 8y ago
Then just store session ID there and get rid of JWT.
- indeyets 8y ago
  There's big difference between fetching session from db and validating id via short local (push distributed) revoke list. Well, that's if project is large enough to saturate storage :)

cryptica 8y ago

This article is propaganda. This is not the first article of its kind; they just keep popping up over and over on HN with the same poor arguments. I usually take the time to write long explanations as to why these points are invalid but I'm tired of arguing with these people. The real reason for these articles I think is that some developers had a very traumatic experience with a poorly implemented JWT authentication system once in their career and now nothing will change their minds about JWTs. Maybe JWTs don't make as much sense for HTTP but for WebSockets they are absolutely crucial. With WebSockets for example, you can push the JWTs to the clients so you can make them with very short expiry: e.g. even 10 minute expiry is possible... Issuing/renewing JWTs with very short expiry helps avoid the need to explicitly invalidate them... If used correctly, JWTs can take a lot of load off from the database. I could go on for a long time about the benefits of JWTs with WebSockets but to summarize the best aspect for me is that you can push them to the client with short expiry and also that you can automatically renew/re-issue them on an interval while the connection is alive... It also works well for dealing with socket reconnects and saves database lookups.

CiPHPerCoder 8y ago
> This article is propaganda. Someone else called it FUD, now you're calling it propaganda. I'm seeing a pattern. > This is not the first article of it's kind; they just keep popping up over and over on HN with the same poor arguments. I usually post long explanations as to why these points are invalid but I'm tired of arguing with these people. ...they said, commenting on an Internet board where discussions (a.k.a. arguments) often unfold with these people. Why are these arguments poor? In what sense does "JWT instead of server-side storage" make a better engineering decision? > The real reason for these articles I think is that some developers had a very traumatic experience with poorly implemented JWT authentication system once in their life and now nothing will convince them otherwise. Your ad hominem straw man argument notwithstanding, there are two orthogonal arguments that JWT defenders seem to conflate: 1. Don't misuse JWT in places it wasn't designed for. <- You are here 2. JWT is an error-prone cryptographic design and should be replaced with a better standard. You can agree with one without agreeing with the other. > Maybe JWTs don't make as. much sense for HTTP but for WebSockets they are absolitely crucial. Would PASETO be a better fit than JWT for your envisioned WebSockets use case? https://github.com/paragonie/paseto/tree/master/docs https://github.com/paragonie/paseto/tree/master/docs

jayd16 8y ago

If you don't care about invalidating single user sessions or any of the other downsides, it works pretty well.

giobox 8y ago

JWTs have long been a favourite topic of software engineer bloggers as they do raise a lot of interesting technical questions. Whether we can take this as evidence of a big following in actual production implementations I’m not so sure, but if forced to guess I suspect they are exceedingly rare (compared to stateful systems) outside of programmer side projects. I’ve rarely ever seen stateless auth used on anything serious, as others have noted many times before the issues with invalidating previously issued tokens often removes the “stateless” part, after which you are just as well using more traditional mechanisms.