> In fact, in most web authentication cases, the JWT data is stored in a session cookie anyways, meaning that there are now two levels of signing. One on the co

> In fact, in most web authentication cases, the JWT data is stored in a session cookie anyways, meaning that there are now two levels of signing. One on the cookie itself, and one on the JWT. This sounds like a bug in someone's implementation of JWTs; most JWTs are not signed twice. It's thus not a valid criticism of JWTs. > If you’re building a simple website like the ones described above, then your best bet is to stick with boring, simple, and secure server side sessions. Instead of storing a user ID inside of a JWT, then storing a JWT inside of a cookie: just store the user ID directly inside of the cookie and be done with it. This is conflating two very different things. Sticking with boring, securing server side sessions… sure (though we're eliding how one would actually implement that, but let's assume it's by sending a sufficiently long, unguessable token in a cookie) but then we continue with "just store the user ID directly inside of the cookie" — no! The point of the JWT is the authenticate the user; just sticking a user ID into a cookie doesn't do that; the user could just change the ID in the cookie to whatever, and be done with it. I'd hope the author means "stick the user ID into the session-side storage" (that's associated with the client in some means, likely by an unguessable token as mentioned earlier), but earlier in the article we make the same mistake: > If we store the ID in a cookie, our total size is 6 bytes Except, no, you're going to need to store that server-side, and send a token, which will realistically be 16 bytes, not 6. The comparison mostly still stands, since there isn't a significant difference between 6 and 16 bytes. > For storing a simple user session, that is a ~51x size inflation on every single page request in exchange for cryptographic signing (as well as some header metadata). It's not a 51x size inflation on every request. That datum is 51x larger, but the request itself includes plenty of other things. This concern will diminish greatly as HTTP/2 is adopted, I think: HTTP/2 is capable of compressing headers, but in addition to that, multiple requests sending the header can essentially say "let's call this header header #1 and then reference it w/ that number on subsequent requests, greatly reducing the transfer required for common, repetitive headers. If you're on AWS, ALBs support it, so it should be very accessible for most folks w/ browsers. (Client-side programming libraries are another thing, but it'll get there.) > You’re Going to Hit the Database Anyway The point is that you can hit the database one time less; yeah, you might need the user object, but you might not. But the suggested alternative of using server-side storage requires a DB lookup in addition to looking up the user object: we've got to first translate the session token in the cookie into a user ID, and then from there get the user object itself. (Perhaps you can, in some cases, JOIN these if you're using a relational DB; but it still bites you if you don't need the user object, and even if you do, the additional disk read isn't going to be faster than checking a signature. If you're putting just the user ID in the cookie, and signing it, you're just re-inventing JWTs. Perhaps you'll save a few bytes, but you lose out on what are hopefully more robust, feature complete libraries, and a common, familiar format.