How To Handle Authentication with Micro-Services

#microservices #node #backend #authentication

With micro-services, and more generally distributed systems, come a lot of new challenges. One of them is how to handle authentication.

If you are unsure about the exact properties of micro-services and the challenges that come along, feel free to read about it more in-depth:

Understand the Difference Between Monolith, MicroServices, and Distributed Monolith

Verify your knowledge of modern software architecture

blog.scalablebackend.com

Authentication & Authorization

Actually, authentication is not the only step we have to manage, but also authorization.

If youre not sure about the difference, Auth0 reminds us that:

In simple terms, authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.

In practice, you can see authentication as the process where you send your email and password. You usually retrieve something that identifies you as the user, which you send along with other requests.

That way, on every other request, the server knows who you are and what resources you have access to. He can then decides if you can access certain endpoints, this is authorization.

Now, I would like to differentiate authentication systems into two groups with different challenges. They are stateful and stateless authentication systems.

Stateful authentication

In a stateful authentication system, you need to retrieve the users information every time hes making a request.

For example, after authentication, you can retrieve a unique id that ties you to a user in database. That way, the server can find who you are, without sending your e-mail and password every time.

But the server still needs to verify the users information that is tied to the unique id youre sending. Only then can he decides if you can access a given resource.

That means, even if youre sending a unique ID that identifies you, the server has to retrieve the user information before handling a request.

This authorization step becomes problematic when it comes to micro-services. If youre doing micro-services well, you want to avoid high coupling, which implies two things (among others):

Separate database
No synchronous communication (request/response) between services.

That means, with the current state of things, we cannot authorize a user on a service outside of the one dedicated to authentication.

Now, we have to think about a way to make authorization possible but keep micro-services independent and lowly coupled.

There is one main solution: managing authentication through an API gateway.

Here, we use an API gateway whose role is to proxy requests to the right service. But, before proxying requests, it checks if the user sent an ID he wants to authenticate with.

If he did, the API gateway retrieves the data related to the user and adds it to the request before it gets sent to the right service.

For example, it encodes the user information inside a string, that is passed with a header.

This way, any service can decode the user information, without relying on the user service.

In my opinion, stateful authentication is simply not a great authentication system when it comes to micro-services.

It makes development and maintenance harder, has a bad impact on performance, and opens the door to security exploits.

While the previous solution is possible, I would prefer using a stateless authentication system.

Stateless authentication

In a stateless authentication system, the users information is stored by the client. That means, once you are authenticated, there is no need to retrieve the users information.

For example, a stateless authentication system can be set up using JSON Web Token.

https://blog.scalablebackend.com/vulnerabilities-in-authentication-with-jwt

Here, the process becomes much more straightforward. We generate a JWT by authenticating to the user service and sending it with requests to other services.