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.