[unqueued]

No, with JWT parsing it doesn't even have to look anything up, cached or otherwise. The JWT itself contains the information directly.

I could have a server that doesn't have any access to the database at all, and it could still render content for the user.

And if the server is for something critical, like purchases, it can still use redis on each request to verify that a JWT is still valid.

[P5fRxh5kUvp2th]

I was responding to this:

> To give you an example, using a traditional session cookie model, whenever my server gets a request, it has to look up the associated session info, and then possibly join multiple tables

It does this on initial logon and then stores it in cache. You can think of a JWT as cache as well.

The point is, it only happens once for both.

[nithril]

Still not comparable. Session cookie requires a session datastore server side. It then requires to enable sticky session, to replicate the session between the server or to have a distributed datastore. if user information are cached it will require either a local cache or a distributed cache.

JWT token does not require that.

Both solutions requires invalidation.

[P5fRxh5kUvp2th]

I'm unsure why you're so hell-bent on arguing something so silly, but at the end of the day you made a mistaken point and I responded to it.

You want to try and move the goalpost that's on you, but your point about the joins is flawed. As is the rest of it, but I'm certainly not going to waste my time.

[supermatt]

you can use signed cookies for sessions - which have none of the drawbacks you mentioned. i.e. session data and expiration form the payload, and you sign the payload - then you validate the expiration and signature on subsequent requests.

[imnotjames]

Assuming you mean express' cookie parser signed cookies? Or maybe rails?

Solves some of the session problems..

Benefits:

Cookies - when set to http only + secure only are safer?

Drawbacks:

They're not cross-compatible No expiration baked in No not-before baked in Limited to hmac validation (no public key crypto options that I know of)

Unless you mean using a JWT as a cookie value. I guess that could work?

[supermatt]

no - i mean the generic concept of a signed cookie as I described, which would have none of the drawbacks you mentioned. They can even be encrypted, if desired.

There are many, many implementations in use "in the wild". They are just signed payloads, so they can contain "expiration", "not-before" or whatever else you think isnt "baked-in". You can use any method of signing them, but would probably make sense to use a strategy that is considered secure :) No doubt the libs you mention can be extended trivially with this "missing" functionality.

Signed/encrypted cookies predate JWT - they even predate JSON...

Im not presuming that they are better/worse than JWT, just responding to the incorrect statement about cookie based sessions requiring server-side storage