12

Should microservices be responsible for handling their own authorization or you think it's better to have a separate authorization service that is shared across all or a subset (within the same business domain) of microservices?

To me the latter makes more sense as it makes it easier to apply changes, enforce policies; it is DRY etc. However it can easily get out of hand by all sorts of services dumping their rules into one place, and also concerned about the network overhead.

Any thoughts?

Improve this question

2 Answers 2

Reset to default
7

I would use a central, unified authentication system and have separate permissions/stats for each microservice (sort of like how I can't yet upvote on this stack exchange site but I can in stack overflow while using the central stack exchange authentication system). One of my current projects will involve this approach in the near future, which will be nice; the previous development work involved creating a HIPPA compliant system, necessitating a second level of authorization/authentication, and it is a time consuming annoyance to daisy chain authorizations from legally separate but functionally inseparable components of the system. The debugging process involves a lot less joy than a simple oauth login or an api with appid and x-auth headers.

Which to use depends upon the specific requirements of a development roadmap, but I would choose the simpler approach where possible to avoid excessive overhead and development time/effort.

Improve this answer
2
  • We do use OAuth2 for authentication, and I'd like to follow the same principle--that is, having a central service with a single, well defined responsibility--for authorization, rather than duplicate the functionality and scatter logic across services. To me it is a violation of the domain boundary. I agree though that it means we'll have to sort out isolation of service rules (ala stackoverflow, programmers etc).
    – morcmarc
    Jun 9, 2015 at 12:51
  • 2
    You could potentially have global permissions that are overruled by service specific permissions, useful if a handful of core microservices use the same permissions. The microservice specific permissions should probably be stored in the app infrastructure for that microservice to avoid potential performance issues for the central authentication service.
    – Jonathan Voss
    Jun 9, 2015 at 16:15
5

Each microservice should not have to do its own authentication, but it does need to do its own authorization.

Source

And this makes perfect sense. I'm assuming there is no doubt about central authentication. But authorization is pretty confusing.

Considering that number of micro-services can grow upto hundreds, thousands, A central authorization service should be responsible for listing permissions only, but not validating those permissions. Individual micro-service may have to approach differently to validate permission.

This central authorization service, may need to get models from different services, and approach differently to take decision, it may look easy and pretty in the beginning. But could be chaos later on.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.