[jusob]

A lot of bad arguments against JWT tokens. These items are definitely something you can address with JWT token: * expiration date * invalidation * change of roles or any significant change in user attributes

Moe important, the list of issues would be the same for a session cookie: if you don't expire the session on the back-end or reflect changes in the user attributes, same issue.

Basically, apply the same best practices for session tokens or JWT token and you'll be fine. You can also put the JWT toke in the cookie, it does not have to be stored in the browser local stroage.

[aobdev]

What makes this a bad argument against JWTs rather than a good argument in favor of using built-in features of the platform? I agree that any purported issues with JWTs are solvable, but if you don't need the benefits they bring over sessions, why use them at all?

I think the premise of the article, which I wholeheartedly agree with, is that for 95% of software projects developers should choose the simplest implementation necessary to meet the requirements. Sessions come for (almost) free with the framework and most browsers, but JWTs have an additional cost for the problems they solve, which are usually poorly understood upfront.

[jay-barronville]

Claiming that technology A shares the same issues as technology B while technology B is all the hype doesn’t exactly spell out why I should use technology B over technology A.

And this is assuming I actually accept your claim that they share the same issues . . .

[remexre]

I think the selling point for JWTs are that they're a mostly-standardized way to do auth tokens such that you only need to do one very simple and cheap database query (is this a token that has been invalidated but hasn't yet expired) rather than a larger number of database round-trips to implement various authorization checks.

[MrJohz]

But that's true of session auth as well. The only necessary check is "does this session token exist and have a creation date within the expiry period", which should be a single, fairly quick database query for all but the most extreme "at scale" cases. You should not need multiple round trips to validate that.

The main use cases for JWT are:

* I want to create a session token that I _never_ want to revalidate against a database, and still trust that the only way it can exist is if a user has logged in at some point. This means that you're not going to be and to log a user out of your system, but that can be a valid trade-off in some situations (e.g. low-security applications where the cost of storage is very high, or microservice architectures where the token can be validated on ingress but doesn't need to be revalidated later).

* I want to include role (or other) information directly in the token for the sake of convenience, so I never need to pull information from other sources (in which case there are definitely other ways to do this, but just using a JWT library and using the result as a session token might be easier than the alternatives).

But most cases of using JWT tokens that I've seen has basically involved using them as overly complicated session tokens with all the same problems, and none of the benefits that JWT itself can bring. In that case, you may as well just take the easier option in the first place.

[akira2501]

> I want to create a session token that I _never_ want to revalidate against a database

There's the middle ground as well with a long lived authentication or refresh token and a short lived authorization token.

> I want to include role (or other) information directly in the token for the sake of convenience

Once I started seriously developing cloud solutions, this became indispensable. It's not just convenient, it directly reduces expenses.

[MrJohz]

A refresh/access token flow definitely can help by reducing the number of long-lived tokens floating around, but it's not really related to the type of token you use. The access token could be a JWT token, but it could also just be an opaque random string, or anything else that's convenient to pass around. It just so happens that reducing the longevity of tokens is useful if you don't want to revalidate tokens against a database.

JWT tokens definitely have their place, I don't want to imply that they're useless. They're a tool with tradeoffs like every other tool we use. But I've seen a lot of projects using them without understanding those tradeoffs, and then creating either very inefficient, overly complex, or subtly insecure applications as a result.

[akajla]

> I want to include role (or other) information directly in the token for the sake of convenience

This works up until a certain point. Once you get past simple RBAC to more fine-grained (resource-based) authz, jwts don't scale: https://medium.com/building-carta/authz-cartas-highly-scalab...