joepie91's Ramblings

Almost a week ago I published an article explaining why you shouldn't use JSON Web Tokens as a session mechanism.

Unfortunately, it seems I've found the upper limit on article length before people stop reading - many of the commenters on Reddit and Hacker News kept suggesting the same "solutions" over and over again, completely ignoring that they were already addressed and found impractical in the article itself.

So, this time, I'm going to illustrate it with a slightly sarcastic flowchart.

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.
• 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.