In the previous post we saw a way for handling authentication using an API Gateway and an Identity Provider. Just to refresh the concept, here’s the basic diagram:

</figure>

The Client will call the API Gateway, which will ask the Identity Provider to (ehm) provide the user details. The Client will get redirected to an external area where the user can login. At this point the Provider will generate a token and pass it back to the Client, which will then attach it to every call to the API Gateway.

So now that we have our user, we need a way to check his permissions in every microservice.

An option could be using Claims-based authorization , which basically means storing every permission that the user has on the entire system as claims on the token.

When a microservice receives a request, it will decode the token, verify it and then check if the user has the required permission claim for the requested action.

It’s a very easy mechanism to implement and works pretty well but also means that we’re sending back and forth a “fat” token, bloated with a lot of useless information for most of the calls. The permission claims are an interesting information only for the microservice that cover that specific bounded context. All the other will still receive the data but it won’t add any value.

Another option is to add an Authorization microservice, something like this:

<figcaption>Authorization Service</figcaption></figure>

This new microservice will basically own all the permissions for every user in the system.

When a microservice receives a request, it will decode the token and verify it. So far so good. Then, if the action requires authorization, it will make a call to the Authorization service, asking if the user has a specific permission.

This way we have decoupled the decision from the microservices, moving it to a specific service that does a single job: handling user permissions (and probably stuff like profiles/roles too ).

Did you like this post? Then