How Does Auth0 Recommend Handling Authorization in a Microservices Architecture?

Get Help
, ,
3

Hi @kriseva

Welcome back to the Auth0 Community!

Regarding your questions:

  • The general recommendation would be for the permissions, roles and other necessary data to be passed in through the access/id token during authentication via a PostLogin Trigger. A very good example of this is shown in the solution for this community post. You can also follow the approach of a centralized service which would be handling all of this, however, I believe the previous option is better since your application will be able to access these elements directly instead of having multiple API calls made to Auth0 in order to retrieve the necessary information to handle authorization on your platform. Our documentation also recommends to store any kind of access control data inside app_metadata since this cannot be changed by the user. I believe the following documentation on Authorization could provide you some extra insight on the approach and best practices you should take into consideration:
  1. B2C Authorization
  2. B2B Authorization

  • Since an RBAC approach would be best for your current architecture, including any necessary data ( roles/scopes/permissions/tenants associated with the user) would be for the best as I have explained above.

  • Depending on your approach, both Organizations or tenant modeling through custom claims/metadata are suitable approaches. You would need to take into consideration that the organizations feature will provide another level of user separation within the tenant which can be suitable if both B2B and B2C users will have access to the platform since roles and other attributes can be managed within it. You can also model authorization on your platform depending on the organization that the user is part of since information such as organization_id will be passed in automatically in the ID Token. Otherwise, instead of depending on organizations, this can also be simply achieved by storing the necessary models within metadata/custom claims since other data (such as the roles/permissions) will also be included inside the access/id tokens during the authentication process.

  • Including the plan-level feature flags inside the tokens would be the best approach. As mentioned above, since most of the authorization data will be included inside app_metadata or custom claims, these would be easily accessible by your platform and you would not have to make unnecessary API calls to Auth0 in order to retrieve and check this data.

With all of these taken into consideration, please keep in mind that when managing Microservice authorization within your platform, always provide the necessary permissions/roles whenever they are being requested by the user ( following further authorization in order for these to be assigned to them) instead of assigning them directly to the user so that they do not receive any unnecessary access within the platform. I would also advise you to read more about Microservices on our blog and you should be able to find other related articles on the matter!

I hope this helps your implementation!
Kind regards,
Remus