3 ms·
« If we store the ID in a cookie, our total size is 6 bytes. » No. What? No. You can't compare a signed JWT with a bare user ID. The proper comparison is a si
by phyzome 8y ago
« If we store the ID in a cookie, our total size is 6 bytes. »
No. What? No.
You can't compare a signed JWT with a bare user ID. The proper comparison is a signed JWT vs. a cryptographically random session identifier with sufficient entropy. It's still smaller than the JWT, pretty much by definition, but make the right comparison, please.
- lostcolony 8y agoHe -does- indicate "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)." So he admits that the signed part is the tradeoff. But I totally agree with you, barely mentioning that, when that's the whole point (JWTs are used for authentication/authorization, not just easily faked identification), is incredibly disingenuous. Never identify users on the client side with something that isn't cryptographically secure. Somewhere, you or another developer will end up implicitly believing that ID is trustworthy, and you just introduced a critical security flaw.
- phyzome 8y agoA pretty common approach is to just give the user a version 4 (random) UUID as a session ID, which is 36 bytes in standard format. 304 / 36 = 8.4x, which is a much less impressive inflation.