How To Handle Authentication with Micro-Services
Tags: microservices, node, backend, authentication
Published: 2023-08-16 17:01:56

---
title: How To Handle Authentication with Micro-Services
published: true
date: 2023-08-16 16:58:06 UTC
tags: microservices, nodejs, backend, authentication
canonical_url: https://blog.scalablebackend.com/how-to-handle-authentication-with-micro-services
---

![Locks](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/roydni2vyy3cqj5opsir.jpg)

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:

{% embed https://blog.scalablebackend.com/understand-the-difference-between-monolith-microservices-and-distributed-monolith %}

## Authentication & Authorization

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

If youre not sure about the difference, [Auth0](https://auth0.com/docs/get-started/identity-fundamentals/authentication-and-authorization#what-are-authentication-and-authorization-) 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.

![Stateful authentication](https://cdn.hashnode.com/res/hashnode/image/upload/v1691951776709/3cd5ebaa-afa9-4d60-88db-5638cd025833.png)

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.

![Stateful authorization](https://cdn.hashnode.com/res/hashnode/image/upload/v1691951810171/a1f8acc9-ddd5-4f21-b725-a7986b17c19d.png)

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.

![Stateful authorization - cannot access](https://cdn.hashnode.com/res/hashnode/image/upload/v1691951841554/4022f2ee-b0c4-4db6-b0d4-cd8153bd8db6.png)

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.

![Authentication through API gateway](https://cdn.hashnode.com/res/hashnode/image/upload/v1691951929791/e87a3b80-e698-47ac-a25b-869a544ebc5d.png)

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](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.

![Stateless authentication & authorization](https://cdn.hashnode.com/res/hashnode/image/upload/v1691952128480/6b2b84d4-7233-4d70-aedc-8c72298aedf8.png)

Other services dont need to reach the user service as the user information is self-contained.

It makes everything simple by design and helps a lot in keeping our services completely independent.

> While this is my opinion, its definitely my favorite way to handle authentication with micro-services.

* * *

Are you looking for a more **in-depth** , and **practical** course on micro-services? Good news, I teach micro-services in a **complete guide** :

{% embed https://www.scalablebackend.com/ %}

* * *

Cover photo by [Max Harlynking](https://unsplash.com/@harlynkingm?utm_source=medium&utm_medium=referral) on [Unsplash](https://unsplash.com?utm_source=medium&utm_medium=referral)