In the last few weeks, I’ve started working mainly on a quite important part of the system: adding authentication and authorization to some of the microservices that compose the whole application.

For a while, I used to work for a quite well know Company on the internal sales tools. In a nutshell, we could say that is an enormous e-commerce store, but of course, there’s more on the plate than that.

But let’s go back to the topic. As I was saying, I’ve been tasked to add authentication and authorization to a bunch of microservices. Of course, we were already checking the user identity before. And yes, we care a lot about who can do what. But we are constantly pushing to do more and more and add functionalities on top of the others, so one nice day we got from the architects a whole lot of new requirements to implement.

And so the fun had begun.

In this post I won’t go into the details of the actual implementation, however, I’ll share with you one of the strategies that can be applied to solve this kind of task.

First of all, for those of you who still don’t know, authentication is the process of identifying who the user actually is. Hopefully, if the credentials are correct, this will generate some kind of user object containing a few useful details (like the name, email, and so on).

Authorization instead means figuring out what the user can do on the system. Can he read data? Can he create contents? I guess you got the point.

In the microservice world, authorization can be handled more granularly if the bounded contexts are defined properly.

Now that the basics are covered, let’s try to move on to the juicy part! Normally, when talking about microservices, one of the most common architectural design patterns is the API Gateway:

The idea here is to have a layer in the middle between the client and the actual microservices. This Gateway can build and prepare the DTOs based on the client type (e.g.: a mobile might see less data than a desktop), do logging, caching, and handle authentication as well. There are, of course, many more things it could do but that’s a topic for another post.

So how this gateway can help us? We need to introduce another block: the Identity Provider.

Here’s the flow: the Gateway will call the Identity Provider, possibly redirecting the user to a “safe zone” where he/she can enter the credentials and get redirected back to our application, this time with a nice token containing the user details.

There are several types of token we can use; cool kids these days are using JWT. Quoting the docs:

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. 

Pretty neat, isn’t it?

Now we got our user authenticated in the Gateway, but we still need to handle authorization at the microservice level. We’ll see how in another post of this series!