5 ms·

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 tak

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
- patterned867 8y ago
  > Someone else called it FUD, now you're calling it propaganda. I'm seeing a pattern. Maybe you should talk to someone about the patterns you are seeing. Maybe you can connect more unrelated things together to paint a mental portrait of others. Thanks for being inclusive.
detaro 8y ago
Could you explain why they're important for WebSockets? Hadn't heard about them in that context before.
- EADGBE 8y ago
  My guess is that a database read/write isn't necessary with JWT, and so WebSockets flying by in a scaled system aren't impeded by this extra layer of complication.
- jjeaff 8y ago
  Probably just because web sockets tend to be used for frequent updates and jwt allows you to authenticate a user without necessarily pinging your sessions table on every single call.
  - dvlsg 8y ago
    Do you have to ping auth on every websocket communication? I feel like you should be able to auth once when you open the connection, and then keep track of the intended session timeout locally (unless you expect external factors to extend that timeout I suppose). Unless that's in regards to checking whether an auth has been blacklisted, which isn't something jwt solves, as far as I can tell.
ldng 8y ago
> I usually take the time to write long explanations as to why these points are invalid Could you link to one of your long explanations ? I'm interested in a rebutal but understand it's annoying to repeat yourself.

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

patterned867 8y ago
> Someone else called it FUD, now you're calling it propaganda. I'm seeing a pattern. Maybe you should talk to someone about the patterns you are seeing. Maybe you can connect more unrelated things together to paint a mental portrait of others. Thanks for being inclusive.

detaro 8y ago

Could you explain why they're important for WebSockets? Hadn't heard about them in that context before.

EADGBE 8y ago
My guess is that a database read/write isn't necessary with JWT, and so WebSockets flying by in a scaled system aren't impeded by this extra layer of complication.
jjeaff 8y ago
Probably just because web sockets tend to be used for frequent updates and jwt allows you to authenticate a user without necessarily pinging your sessions table on every single call.
- dvlsg 8y ago
  Do you have to ping auth on every websocket communication? I feel like you should be able to auth once when you open the connection, and then keep track of the intended session timeout locally (unless you expect external factors to extend that timeout I suppose). Unless that's in regards to checking whether an auth has been blacklisted, which isn't something jwt solves, as far as I can tell.

ldng 8y ago

> I usually take the time to write long explanations as to why these points are invalid Could you link to one of your long explanations ? I'm interested in a rebutal but understand it's annoying to repeat yourself.