Authorization in microservice architecture

Question

currently I develop a backend based on the microservice architecture. Unfortunately, I have a problem how to realize the authorization.

So let me explaine my system - there are the following services:

• OAuth 2.0 Service (issuing JWT)
• Group Service
• Some Ressource Services (e.g. ToDos Service)

Every user is in one or many groups. Each resource (like a ToDo list) also belongs to a group. That means if some user creates a todo list, that list gets stored in the name of the group.

Szenario:

• User A is in group A
• User B is in group A and B
• User C is in group C
• User A creats a ToDo list in group A.
• User B modifies this ToDo list (he is allowed to do this since he is also in group A)
• User C also tries to modify this ToDo list, but he shouldn't allowed to do this since he is only in group C.

Has any body a great idea how I could realize this in a microservice architecture and keep the dependencies between the services on a minimum?

Certainly, I could ask on every request the Group Service if the user is in the group to which the resource belongs to. But so I get a really hard dependency between the Resource Services and the existence of a Group Service - I like to avoid this dependency. Another option would be to store all groups, to which the user belongs to, in the access token. But with this option the client has to ask every time the OAuth Service for a new token when the user gets a member of a new group.

So is there any other option how I could realize this szenario?

Answer 1

I would suggest to put the authorisation handling into a API gateway. When there is an incoming request the following steps are executed

1.The API gateway hits the OAuth server to get a transparent token which contains the access roles and groups of the user 2.The API gateway then calls the to do services with the access token , which the to do services use to decide if a particular user is authorised.

The advantage of this integration pattern is that the individual services don’t have to call the group service to get the roles.

Answer 2

So, you have three domains:

1. Authentication: responsible for identifying the user
2. Authorization: responsible for restricting access to resources
3. Todos: your core domain

You have done well identifying three bounded contexts, one for each domain and implemented in three microservices (MS). You are conforming to the best practices regarding DDD.

No, your question is how could you integrate those three microservices in such a way that the system is resilient, i.e. its microservices continue to work even if some of the other microservices fail.

You have two options regarding integration (communication between microservices):

1. Synchronous communication: every time the Todos MS receive a request, it queries the Authorization MS to check if the user is permitted to do what it wants. This has the advantage that is simple to implement but it has the disadvantage that is susceptible to cascade failure: if the Authorization MS fails then this MS also fails. So, this option is not good for you.

2. Asynchronous communication: somehow in the background, there is some data that is replicated from the Authorization MS to the Todos MS. You have at least two options for this replication to be done: a) in cron or scheduled tasks or similar and b) using a event driven architecture. This has the advantage that provides more resilience but it has the disadvantage that is more complex, harder to implement. This option seems to fit your need.

Further reading:

• Building microservices