Okay, so you have decided to break your old and outdated monolith application into a more modern and efficient microservices architecture.

One of the first problems that will arise comes from the fact that a distributed architecture means your small pieces aren’t tied to each other anymore, they will have to talk to each other through a pattern of communication called REST, and no longer they will share in-memory data among them.

Well, it just happens that one of the most important pieces of data for your whole application is kept in-memory and shared throughout all modules of your application: the user session.

When you do a little research on microservices authentication and authorization, one technology comes up as the best, if not the only, solution: JWT.

Basically, this approach suggests that you put all of your session data into a signed / encrypted hash (the token) and send it back to the client that has logged into your application.

So, with every request, the client will send back that token (usually in the request header), and then you can verify the authenticity of the token and extract the session data from it.

Session data in hands, you can send it to any service you need until you fulfill that request. You can set up a serverless function to decrypt and verify the signature of the token, or even delegate this task to you API Gateway.

This looks so neat and elegant at first, but wait a minute … it looks fairly more complex than what it used to be, right? Let’s take a look at how it used to work with our monolith application, and why did it have to change so drastically.

#microservices #redis-and-jedis