othreecodes
commented
5 years ago Approach 2: Global Authentication, Service Authorization This approach is likely the best fit for most people. Keep the clunky authentication layer at your front-end global services layer. Then, when the front-end calls the back-end microservices to do an actual job, it can provide a security context. This allows the microservices to not care how someone is authenticated, but is still able to maintain the business logic decision making of what actions this security context is allowed to perform.
Let us take an analogous model of logging into your desktop computer — Windows, Mac, Linux does not matter. You enter your credentials and a login process authenticates you and then creates a desktop process assigned to your user context. All applications launched from that point on are associated with your user context and all file system, network, etc. access is authorized using that single user context. Your applications and the kernel do not care how you obtained that security context, but they will sure as heck keep you within the boundaries of what you are allowed to access.
This is essentially what I meant by saying “I do not believe user-level authorization stops at the gateway.” The authentication can stop, but as calls are made into the back-end microservices, a security or user context should come along with any calls such that the microservices can enact their own business logic of what the caller is allowed to do.
Note: This requires that you have strong authentication and authorization between your services (by using something like Istio and its mTLS). You must be certain that when you get a request to do something in your microservice with a given security context that the security context can be trusted. If any service within your microservices mesh is able to call you and provide a faked security context… That is just a recipe for disaster.
Do authentication globally, and authorization in every microservice
pros
cons