3 ms·

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

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.

manigandham 8y ago
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.
- CiPHPerCoder 8y ago
  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-bad-standard-that-everyone-should-avoid https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...
  - manigandham 8y ago
    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.
    - CiPHPerCoder 8y ago
      > 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?
      - manigandham 8y ago
        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.

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.

manigandham 8y ago

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.

CiPHPerCoder 8y ago
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-bad-standard-that-everyone-should-avoid https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...
- manigandham 8y ago
  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.
  - CiPHPerCoder 8y ago
    > 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?
    - manigandham 8y ago
      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.