[foray1010]

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.

[Spivak]

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.

[dwild]

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

Isn't that JWT?

[sk5t]

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.

[idoubtit]

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.

[Spivak]

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?

[Arnt]

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?

[Scarblac]

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