Hacker News Reader

Comment by nijave | Hacker News Reader

That video is ridiculous. The whole time is spent talking about how cookies are superior to local storage which has little to do with JWT. You can use JWT and store it in a cookie. Session cookies are most certainly not automatically signed. Signing a session ID provides absolutely no value (signing claims, however, does). Revocation is exactly the same for both of them. JWT has a standard jti field for the session ID. I'm also not sure why you'd store all of a user's information in a JWT. You can just put in the minimal information to accomplish what you need.

View on HN

If you cryptographically sign the session cookie, as suggested in the video, then you accomplish the exact same thing as a JWT token - so, then why use JWT at all, if you going to look up the session data from the database in any case.

JWT was meant to be stateless, if it's not, then it's just a layer of unnecessary complexity with potential security and implementation flaws.

depends on if need to call other apis like microservices, you can use the JWT on behalf of the user to request the contents from other services. JWT also introduces `scope` which determine services user consented and allowed your backend to call. These things are not supported by a simple session cookie.

That's precisely the use case for JWT I recently had to work with, where cookies are irrelevant.

The web server gets a token from the API server, then prepares a few JSON messages that the web client will send asynchronously with JS. Since each message content is signed, the web client can't tamper with what is sent to the API. JWT was perfect for this 3-tiers messaging.

I mean is all this complexity really worth "I can send data to an untrusted client so that it can later send it back to me?" compared to just storing that data somewhere like Redis?

Then you have to provide a consistent view of the database across all server nodes, and the database updates need to propagate to all of your servers more quickly than the clients can issue requests. How complex is JWT compared to that?

He never said "back to me". Back to somewhere. That may or may not know that Redis exists.

I mean they're not supported OOB but you're just describing a session cookie with some signed metadata. If "the ecosystem" and interoperability with existing services is the goal then has the advantage.

If you're talking about something bespoke then it probably doesn't.

> you're just describing a session cookie with some signed metadata.

Isn't that JWT?

Delegation via JWT replay downstream? Maybe, I guess, if those other services all have the same "aud(ience)" requirements, or don't bother checking audience. Probably not a design to hang one's hat on.

JWT is basically a spec for how to sign the session cookie. Correct me if I'm wrong but there are 2 fundamentally different ways to do user session management: a) user has a random key that can be compared to stored key (DB, Redis, ...) b) signed session information, probably stored as cookie.

It's possible to add additional information in a JWT. And of course it's complexity that adds additional attack surface, but at least there is some kind of standardization around it.

Nit: JWTs are leveraged to cover a wide variety of use cases outside sessions.

My favorite use for JWT was actually on the backend for Frontend-to-service-to-service auth. It was actually a pretty natural way to flow the user context around without getting ugly with our API calling conventions.

Basically, Clients all used NTLM to talk to the main site, but the main site would use JWT to pass the authenticated user info to the other services being called. The signature ensured that you couldn't spoof, short of being an authorized user that could get an impersonate token for calling the APIs.

But the nice thing was it meant we didn't really have to hit the DB at all in any of this, and it was way cheaper to implement than an API gateway.

Yeah I was hoping for a fair comparison but it seemed like a pretty big strawman. Like he just takes it for granted that "a session cookie is a cryptographically-signed identifier" but that's not remotely standard. At its most common (looking at you, JSESSIONID), simple form, the session cookie is a securely generated random number that is used as an index for state, and signing plays no part. The presenter then goes and talks about how cookies can be used to store other pieces of data in a stateless way, but it all branches from this premise that cookies are crypotgraphically signed, which isn't historically true.

Author here. Random identifiers and encoded objects are both widely used historically. Random cookies might have been more common 2 decades ago when every byte was expensive, but that was a while ago.

If you work mainly in Java for example, you'll more often see JSESSIONID which are random string identifiers, referring to a database containing active tokens and user profiles.

However if you work in Python, you'll more often see objects. Typically something like a user identifier + creation date + random bits, that is encrypted with a symmetric key. It's usually encrypted, not signed, so yet another thing than signed tokens and random cookies.

Sure Django and Flask use secure session cookies but that doesn't automatically make them all secure or signed/encrypted. Most cookies are plain text and there's no reason they need to be secure (they just contain user metadata not auth information)

Reply on news.ycombinator.com