Should each microservice manage its own user-permissions and user-roles?

Question

I have a design issue I am not sure of how to solve.

Let's say my main application consists of 6 modules:

• client
• gateway
• auth-service
• forum
• gallery
• messages

The client is supposed to communicate with the gateway-service only.

Should I have my gateway do the user-authentication (which ideally results in a JWT) and the other 3 productive-services (forum, gallery, messages) just verify that token and retrieve permissions and roles they manage themselves for that given user?

To perhaps illustrate my few troubles, I create a sequence diagram:

Click here for the original draw.io graphics if you prefer that.

I do not want to use any 3rd-party auth-services; I just want my auth-service (which is pretty much done) to register users and let them login. Or should I be managing permissions and roles in that service as well?

I tried to wrap my brain around this issue for months, but I simply cannot find a suitable structure so I can let the user register, login/logout and communicate with various productive services. I am currently using Java for the backend stuff, but the good thing about microservices is, that I do not have to use one programming language for them all.

Any help here is welcome!

P.s.: I read Microservice Authentication strategy and Zuul - Api Gateway Authentication, but both did not seem to apply in my case.

Answer 1

I have worked with the following setup, and it has worked out pretty well:

Login flow:

1. Fresh browser makes a request for a specific resource
2. Gateway service detects the absence of the jwt cookie and redirects to login form
3. Login form talks to auth-service via gateway. Gateway allows non-jwt calls only to auth-service
4. Auth service gives a login-form a newly created jwt cookie and redirects to original URL

Normal operation:

1. Browser makes a request for a resource along with jwt cookie
2. Gateway service intercepts the request and forwards jwt to auth-service for validation
3. Auth service checks signature then timestamp then blacklist and returns a positive or negative result
4. If positive, Gateway service forwards the request to respective backend service, otherwise redirects to login
5. Backend service does not do jwt validation - it just trusts the gateway to send only valid requests.
6. Backend service does check for roles/permissions/entitlements defined in jwt

Logout flow:

1. Browser makes a request to the auth-service/logout
2. Auth service puts the jwt in blacklist and redirects to login form

Now, this is a simple workflow we implemented without any (much) 3rd party help. At some point we did had to use session cookies but that is for other reasons. Note that the system is almost stateless except the blacklist at auth service. One does not simply log out with jwt! We had a REDIS to manage the blacklists. You can implement logout with session cookies at gateway or auth service.

Most of the backend services expected their own set of roles/privileges/entitlements in the jwt. The roles were granted to user by the auth service and were written in the granted jwt. If a new role was grated to a user, the user had to logoff/logon to reflect that privilege. If some privilege is removed, then the user had to force logged off - that is where REDIS played.

Answer 2

It depends on how complex the permission setup is.

If your permissions are super simple, i.e, all services need authentication and have a single a role to work with, you can add at gateway api.

If you need more granular approach you need to do it at the module level. Typically in a micro-service architecture, each service would invoke another service, and having the authorization settings at module level avoids up front knowledge of required permissions needed at gateway api. And you can deploy each of these modules without much thought about other services, have granular permissions at method level etc.

Answer 3

Long time has passed since this question was asked, but I have the same problem and came across this, so leaving my thoughts.

A nice overview of possible options is laid out here: https://www.osohq.com/post/microservices-authorization-patterns (I'm not related to oso in any way, just the blogpost is nice)

In short, what is described there is the following:

• Leave the data where it is (basically what you described in your question, each service doing its own authorization). Easier and faster to get it going, but not responding well to scale (adding more and more teams and services)
• Central authorization. Have a new central authorization service, which will hold all possible policies and roles, and each service will ask the central authorization service for permissions. Something like Policy Server.

What some of the answers here and the other stackoverflow questions you linked discuss is authentication (identity), not authorization (permissions). Both of them preferably should not be mixed in the same service. See this & this for more info.