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