How Does Auth0 Recommend Handling Authorization in a Microservices Architecture?

Get Help
, ,
1

Hello Auth0 team,

We’re integrating Auth0 as the central identity provider in a multi-tenant SaaS platform for business management. Our platform supports b2b, b2c, partners apis talk to our backend..

Our backend is built on a microservices architecture, with services like Booking, Customer Management, Inventory, and Payments — each with its own API surface and access rules.
:red_question_mark:We are looking for Auth0’s official recommendation on:

How should each microservice validate that a request has permission to perform an operation?

    Should permissions or roles be embedded into the access token?

    Or should authorization be handled by a centralized service or token introspection?

What token structure does Auth0 recommend for this model?

    Should we include scopes only?

    Or also embed roles, tenant ID, and fine-grained permissions via custom claims?

What is the preferred approach for tenant isolation and per-tenant role mapping in this case?

    Should we use Organizations?

    Or model tenants via custom claims and metadata?

How should feature access (based on subscription plans) be modeled and validated in a scalable way?

    Should plan-level feature flags be included in tokens?

    Or resolved externally per request?

We’re not looking for general guidance — we’d like to understand what Auth0 officially recommends for secure, scalable authorization in this architecture, particularly when access control needs to be enforced at the microservice level.

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

4

If permissions are stored directly in the token, the token’s size limit might limit the number of permissions we can embed for an enterprise crm like application? what do we do in this case , switch to centralized permission service ?

5

Hi @kriseva,

Given that RBAC is specifically designed for this type of use cases, you can firstly define roles, then add permissions to them - Manage Role-Based Access Control Roles.

The Maximum Request Size for the ‘/oauth/token’ Endpoint is 500kb, which is mostly sufficient in any scenario, while you can also check the Number of Roles/Permissions per User here.

Best regards,
Remus