I am running a microservice based server-less architecture and had built this around the principal of a central authorization service that is called by all other microservices. For info Authentication is handled by interceptors before the services are called.
For the sake of this question I have following microservices
/boats
/cars
/comments
/authorization
If a user called the the Car service and looked up car 123. The Car Microservice would first call the authorization service to check if the user was allowed to see car 123 and if so, the car microservice would return the car to the user. Similarly if the user asked for any comments about car 123, it would call the comments service, which in turn would first call the authorization service to check the users access to car 123 before returning the appropriate comments for that car.
Based on some reading I have been doing (https://groups.google.com/forum/#!topic/microservices/n_jL3atxPhQ) I believe for object level permissions, it may be more useful to embed authorization within the respective api, thus keeping all object & permission information for a domain within that service.
I am not sure what to do when there are reusable microservices providing functionality across all domains e.g. comments, files activities
Approach 1:
Boats and Cars services handle their own authorization. The comments service needs to call out to the boat or car service to handle authorization
/boats
/cars
/comments
Approach 2:
Boats and Cars services handle their own authorization, and proxy requests (with appropriate claim headers) to an internal only comments micro-service. Comments then does not need to handle authorization other than to check claims in the header.
/boats/{123}/comments
/cars/{123}/comments
Are these common or even valid approaches? If so what is a better pattern to use given a number of other reusable services like comments?
