4 ms·
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 id
by 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 agoHow 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 agoYes 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.