Footnote: microservice architectures

Another argument that came up a lot, was that using JWT for sessions is still fine in a microservice architecture. This one is also wrong, but is a bit too complex to fit into a flowchart.

In a microservice architecture where the client talks directly to the services, you will have roughly two types of services:

Stateful services: Something that has a concept of a session or persistence, like a chat service.

Something that has a concept of a session or persistence, like a chat service. Stateless services: Something that does not have a concept of a session, but rather performs individual self-contained tasks, like a video transcoding service.

You don't need to use JWT token as a session in either case. For a stateless service, there's no session at all, so you simply have the application server hand out short-lived, single-use tokens for each individual authorized operation.

For a stateful service, you hand out a new short-lived, single-use token for each service - which is then exchanged on the service itself, for a session on that specific service. You never use the token itself as the session.

In a microservice architecture where the client only talks to the application server, none of this as relevant, as there's no concept of a "session" between services - it's all individual, self-contained actions from the same origin(s). It's probably fine to use JWT tokens there, even if they're not optimal for this kind of case - you're just not using them as sessions.