I'm seeking advice on how we may be able to implement authentication and authorization for multitenancy with slightly different number of scenarios.

We are building a set of API's which of some are internally accessible (within the organization) whilst some will be externally accessible (internet).

The ones internally and directly accessible within the organization may "indirectly" be accessed via more abstracted services that are externally exposed.

due to the complex nature of our business (telco company), consumers of the externally facing API's will come in different forms. Some will be our subsidiaries, whilst others will be 3rd party, vendors and developers.

I'm going to make an assumption that whether they're a large organization consumer or a single person developer - they're all uniquely identifiable the same way.

The tricky part now is that in certain scenarios the resources that publicly exposed may not be allowed to be accessed by certain consumers. example:

  • Subsidiary X can access all resources and CRUD operations on resource Y
  • However, 3rd party Z can only retrieve I'm probably venturing into ACL territory now...

Furthermore, to add complexity to the matter, there are certain "structural separation" scenarios (imposed by the government) that warrant data segregation but I won't go further down that rabbit hole.

There is also the issue of multiple tenants accessing a system that does not cater for multitenancy. :)

So there is a lot there so I'm wondering what are people's opinions, advice and approach to such.

We're hoping that oauth2.0 in conjunction with OpenID with a custom ACL solution could possibly work.


Apologies had issues with my mobile when posting question and half of it got cut out.

Just some general advice to the approach.

Is this something that OpenID and Oauth2 with entitlements server could cater for?

  • You have a lot of text but don't seem to directly ask a question. Commented Nov 13, 2015 at 23:02

2 Answers 2



The above blog entry suggests keeping object level permissions within each microservice. So you can authenticate and pass along user_id (or group_id) via something like OAuth 2.0 and tokens, but do the actual work of authorization / filtering response within the microservice.

This approach keeps the "loosely coupled" spirit of microservices.


Each API consumer is an OAuth 2.0 client, and is registered on your authorization server for certain scopes. OAuth 2.0 scopes can be seen as permissions, so you can already enforce a certain number of access control rules based on scopes. When a client starts an authorization flow, it asks the user his consent for a number of scopes, and the access token generated in the end will "carry" these scopes.

Your resource X may require clients to have a token with scope READ_X, while resource Y requires clients to have token with scope WRITE_Y.

If you need finer grain permissions, you can also give roles/permissions to your users. That's outside the OAuth 2.0 specification though, it will depend on the tools you use.

Multi-tenancy can be implemented in various ways depending on your case.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .