Authentication and Authorization with Microservices and Gateways

Question

I’m am trying to learn Microservice architecture. I am kind of puzzled about how I am supposed to go about Authentication and authorization using Microservices and a Gateway application.

For this situation, lets say I have the following services for, lets say, an eCommerce application: 1. AccountService (manages user accounts) 2. Listing Service (manages product listings on the app) 3. Cart service (manages the items in the user’s account) 4. Order Service (manages the processing of user orders on the app).

From things I have read such as this, there is always mention of an “auth server.” So, my first question is what exactly this auth server do? Its name tells me that it authenticates a user of the application. But, does this imply that this Auth server must store user data? So, does it make sense to make the Accounts Service, which stores user account information, also the auth server as it stores all the information about the user? Or, is the Auth server its own microservice? And if so, what kind of information about users does it store that the account user does not? Should I make the Gateway application the Auth server, as all requests must go through it anyway?

My second question has to do with Authorization among Microservices. Specifically, how does it work? From my research, it seems that this is done through tokens that store permissions. For many technology stacks (be it PHP’s Laravel, Javascript for frameworks like Adonis, Java Spring, etc...), packages for OAuth are typically widely available. So, I guess packages that hide the internal workings kind of contribute to my confusion. But, anyways... From my research, it seems the standard practice is let the OAuth server (again, drom the first question, whatever that really means) handle authentication while the individual Microservices handle authorization. Specifically, this is done through tokens that contain permissions. So, how does a Microservice go about verifying these permissions exactly?

Do I just have the same OAuth packages installed in the individual packages and use their authorization capabilities? But doesn’t this couple the service to that one technology, which is against the philosophy of Microservices? Or, do I do the authorization is the Gateway app as well and have the other microservices just be resource repositories since they are not directly accessible to the public (assuming its Dockerized) anyways? Or some other way?

Thanks again for the help. Again, I am still trying to wrap my head around Microservice architecture. So, sorry if these questions sound too trivial or silly. :)

Answer 1

You have different question and i will try to answer them one by one

Auth server

As name implies it's the authentication server. You can leverage third party Auth servers (Azure Active Directory or auth0 (https://auth0.com)) or you can create your own. When you create your own (not recommended practice) , you have to have manage everything on your own from tokens to security and maintaining user databases ,and that's another microservice in your case. All Auth server does is to provide you access token which validates the user identity. But you may have to save only small set of user info into your database to run your business logic. e.g. your shopping application offer basic/Standard/Premium services to the shopping users and to identify which service the particular user is subscribed to is only possible if you have user ID saved in your database. So your auth server is only responsible to give you token and from there you are responsible to run the show.

API Gateway

API gateway is the entry to your microservices. Gateway is used as single point of entry and offload user authentication , TLS etc. Generally your API gateway is responsible to go talk to Auth server and bring back access token which you can be verified in your API gateway.

Using that token in other microservices is dependent on how you deploy your microservices. APIgateway is generally public IP which is used to enter your system. However if all other Microservices that you deployed are public facing (has public IP) then you have to secure them too. Anyone with Public IP can access your Microservices without even going to Gateway. In this case you have to verify the token with every request entering into any public facing microservice. But if you deploy your microservices inside the cluster (Kubernetes etc) that have private IPs accessible within cluster only then you don't have to worry about authentication. Only your API gateway has access to cluster and cluster sits behind virtual networks/Firewall. So your Gateway is the only way for traffic to come and go.

Hope that helps !