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.

> 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

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

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

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.

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.

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.

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

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

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.

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.

I’m not too sure what you’re talking about but the article is about this confusion.

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.

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.

Then just store session ID there and get rid of JWT.

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

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

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.

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.