The whole point of the "JWT for Sessions" design was to prevent server-side storage.

Otherwise, they could just use a long random string and maybe HMAC it and call it a day.

Perhaps, but what they actually are is a standard way to encode some data. Whether that's a single number or entire user session state is up to you. And how you pass that data back and forth is up to you.

There are some common usage conventions but the limits described in this article are completely arbitrary.

Nobody here was arguing about what JWT is, the article is about how they're often abused in an attempt to obviate server-side persistent data storage in pursuit of "scalability".

The title is "Stop using JWT for sessions" not "Stop using JWT".

The arguments against JWT themselves are wholly separate: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...

The basis of that entire argument is based on a false understanding of what JWTs are and how HTTP state transfer works.

If you want to say that client sessions should not be 100% on the client side and should be split between client/server then just say that. There are pros/cons but at least that is a clear argument instead of misleading about JWTs.

> The basis of that entire argument is based on a false understanding of what JWTs are and how HTTP state transfer works.

I don't even see why you believe this to be the case. The article (and the follow-up) are both pretty clear about what the actual issue is.

Did you read them or just react to the headline?

It seems you are overly defensive about an article that you agree in other comments is "not about JWTs" even though it is titled as such and talks about them at great length.

I think you can also see from my other comments that I know what I'm talking about and my issue is the fact that * instead of discussing client/stateless vs client/server shared state*, this article spreads more misleading information about JWTs and sessions.

adding a database lookup is adding state

The point is that JWTs are irrelevant to this discussion. How you pass data between client and server can be cookies, or another header. How you encode that data can be JWTs or your own format. It is not either/or.

Whether you manage state 100% on client or share it between client and server is an entirely separate topic.