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.
A strongly worded argument against a bad engineering argument is not FUD.
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.
> 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.
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.
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!
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.
The topic is more about session VS JWT, not cookies vs whatever local storage is used in place of cookies.
You can send it all to the client or you can send just an ID and lookup the body on the server.
You can send it to the client via the cookie header or via the Authorization header or something else.
You can encode the data (sent via cookies or auth header) as a JWT or your own encryption scheme.
These are all different technologies working at different layers, which is why comparing JWTs vs cookies vs sessions doesn't really make sense.
the storage of session has absolutely nothing to do with the session. I'm not sure why you keep talking about Cookies it has nothing to do with the problem. JWT can be persisted with cookies as well.
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.
You can absolutely use JWTs as the payload of your cookie. How you pass the session data back and forth is separate from how you encode the session data. Most web frameworks have their own token formats, but you can easily change them to be JWTs.
Using the Authorization header just means you're using a different header, and since it's not automatically sent then you don't have the CSRF issues with browsers, but now you have to manage it more manually in your client-side code.
Regardless of how you encode your tokens, if you want to do instant expiration or other live data lookup then of course you'll need to manage that on your server, whether it's a database, in-memory cache, or something else. The split between where state is managed is irrelevant to the physical transfer and encoding.