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