architecture – Sharing user related data in microservices

I’m having a problem choosing the right approach to sharing some user related data throughout my microservices-based application.

Imagine the following scenario:

Users microservice handles creation of users, but also management of the hierarchy of those users. It has the information regarding which users have Manager role and which User role, but also which Users are subordinates of which Managers.

There’s also a Books microservice which allows for creation and management of Book and related entities. Users can create and manage their own Book, however, their managers should be able to update their Book, too. The authorization of Update endpoint of BooksController should check if the User trying to do the update is the owner, or in the case when he’s not, does he have a Manager role and also if the owner of the Book in question is his direct subordinate. This information is only available in the Users microservice.

I’m considering following solutions to this problem:

  1. A request/response pattern implementation to get the subordinates of the Manager in question – Feels like a very bad option for this, as it’s essentially creating a tight coupling between the services and also creating a single point of failure for both services.

  2. Sharing the Users database with Books microservice (read-only) – another case of tight coupling, however, with no dependency of the Users service to be alive to retrieve the information.

  3. Merging the microservices together – Maybe the line was drawn in a wrong place and those two microservices should become one. However, looking at the Users service, it feels like this sort of scenario can reappear for other microservices that will be introduced to the application. Solving it this way sets a precedence for just merging it all back together into a monolithic application.

  4. Adding the data regarding users hierarchy to the access token as a custom claim and using that data to do Authorize in the Books service – I think it could work. My worry is that I’d be misusing custom claims for passing data that isn’t really ‘part’ of the user.

  5. Other?