3 ms·

> This is just FUD. No, it's an engineering argument that makes several testable claims about JWTs, sane session protocols, and how the two are mutually exclus

> This is just FUD. No, it's an engineering argument that makes several testable claims about JWTs, sane session protocols, and how the two are mutually exclusive. > JWTs are a standardized way to securely encode data into a self-contained token. Cookies are special headers added to HTTP requests to store state. The difference is this: - Sane sessions - Random unique identifiers stored in a cookie - Upon receiving the cookie, the web app looks in the filesystem/database/etc. for the data associated with that session - Can be invalidated by deleting the server-side storage - JWT-based sessions without server-side persistence - All session state is encoded into the cookie - All the trust is outsourced to the client to invalidate sessions. The other arguments follow from this difference. A strongly worded argument against a bad engineering argument is not FUD.

manigandham 8y ago
As stated, how you encode state is different from how you transfer state. It's not an engineering argument if you don't understand the fundamentals. JWTs are a encoding format. You can just put a single random unique identifier in there if you want. And you can use cookies to transfer JWTs automatically instead of using the Authorization header. Either can be checked on every request by the server for further validation. The limitations you wrote are completely arbitrary.
- CiPHPerCoder 8y ago
  It sounds to me like you don't understand what Sven is arguing against in the article. > JWTs are a encoding format. You can just put a single random unique identifier in there if you want. And you can use "cookies" to transfer JWTs automatically instead of using the Authorization header. Either can be checked on every request by the server. This is totally irrelevant! Does your cookie (JWT, PASETO, or whatever) contain more than just a unique identifier? The argument is: Are you storing things like user_id=13455&is_admin=false in the cookie instead of having that entirely server-side? Don't do that, it's a bad design, store that server-side instead. That's literally the argument.
  - manigandham 8y ago
    How you ENCODE data is different from how you TRANSFER data and neither are related to storing state completely on the client vs the server. You can pass JWTs as cookie data, and you can store nothing but a single session ID in the JWT itself. They are completely orthogonal and have nothing to do with the actual argument. It's misleading when the title and the entire article talks about JWTs vs session/cookies.
    - CiPHPerCoder 8y ago
      > That has nothing to do with JWTs. Progress! You're so close to understanding the article. It wasn't ever about JWTs in particular. It was a response to a widespread engineering antipattern of "storing all session state in a cookie then maybe encrypting or HMACing it so you don't have to store anything server-side". JWT was just how developers tended to implement this antipattern. Like, literally, that was the entire point of the entire article that Sven wrote. The examples of apps that do this have become less common since the article was written, so if you're confused by that, you're just missing context, and that's OK. As for "anti-JWT" arguments, I've made them separately from the argument of Sven's claims. JWT is an error-prone cryptographic design. I wrote a replacement standard called PASETO that doesn't contain these foot-bullets. I still don't recommend people use PASETOs for sessions!
      - manigandham 8y ago
        Yes I understand that it's about client vs server managed state and the balance between. You can see this noted in my very first comment. But this article is titled and talks about JWTs at great length with pros and cons, which is completely misleading. The fact that many of the comments here are only talking about JWTs vs cookies and skip over what and where the state is managed only further reflects that confusion. Perhaps a better article should be written and posted.

manigandham 8y ago

As stated, how you encode state is different from how you transfer state. It's not an engineering argument if you don't understand the fundamentals. JWTs are a encoding format. You can just put a single random unique identifier in there if you want. And you can use cookies to transfer JWTs automatically instead of using the Authorization header. Either can be checked on every request by the server for further validation. The limitations you wrote are completely arbitrary.

CiPHPerCoder 8y ago
It sounds to me like you don't understand what Sven is arguing against in the article. > JWTs are a encoding format. You can just put a single random unique identifier in there if you want. And you can use "cookies" to transfer JWTs automatically instead of using the Authorization header. Either can be checked on every request by the server. This is totally irrelevant! Does your cookie (JWT, PASETO, or whatever) contain more than just a unique identifier? The argument is: Are you storing things like user_id=13455&is_admin=false in the cookie instead of having that entirely server-side? Don't do that, it's a bad design, store that server-side instead. That's literally the argument.
- manigandham 8y ago
  How you ENCODE data is different from how you TRANSFER data and neither are related to storing state completely on the client vs the server. You can pass JWTs as cookie data, and you can store nothing but a single session ID in the JWT itself. They are completely orthogonal and have nothing to do with the actual argument. It's misleading when the title and the entire article talks about JWTs vs session/cookies.
  - CiPHPerCoder 8y ago
    > That has nothing to do with JWTs. Progress! You're so close to understanding the article. It wasn't ever about JWTs in particular. It was a response to a widespread engineering antipattern of "storing all session state in a cookie then maybe encrypting or HMACing it so you don't have to store anything server-side". JWT was just how developers tended to implement this antipattern. Like, literally, that was the entire point of the entire article that Sven wrote. The examples of apps that do this have become less common since the article was written, so if you're confused by that, you're just missing context, and that's OK. As for "anti-JWT" arguments, I've made them separately from the argument of Sven's claims. JWT is an error-prone cryptographic design. I wrote a replacement standard called PASETO that doesn't contain these foot-bullets. I still don't recommend people use PASETOs for sessions!
    - manigandham 8y ago
      Yes I understand that it's about client vs server managed state and the balance between. You can see this noted in my very first comment. But this article is titled and talks about JWTs at great length with pros and cons, which is completely misleading. The fact that many of the comments here are only talking about JWTs vs cookies and skip over what and where the state is managed only further reflects that confusion. Perhaps a better article should be written and posted.