We are working on a multi-tenant application where a user, who’s identity is managed by Auth0, could be granted access to multiple tenants. Each tenant could assign different roles to that user. Right now we store the role information for a single tenant in the app_metadata in Auth0, but that won’t work when a user is assigned to multiple tenants. Plus, any time the roles change we have to synchronize multiple users at once which is an expensive operation.
Instead, I would like to source some or all of the user’s profile from an external system (database or web service) via rule. However, when the user authenticates, I’m struggling with how to tell the auth0 rule which tenant they were coming from as the code-token exchange doesn’t give me much flexibility in specifying the tenant.
I was wondering if anyone has encountered that before and what options I have for solving it. I have considered a number of options.
- Continue to synchronize the app_metadata from our system to Auth0, but segment by tenant. I would like to avoid this if at all possible as roles can be re-assigned in bulk and the synchronization process, even with the bulk import is time consuming.
- Cheat a bit and add a Tenant-ID header to the token exchange request. I should be able to access that from the context object in the rule.
- Add something to the issuer or login-hint, but I don’t know if I would have access to that in the rule.
Are there other options to consider?
Hi @sjungers
First: can you define what you mean by “multi-tenant”. It could be that your application has multiple tenants, but they are all hosted in a single Auth0 tenant, or it could mean that your application’s multiple tenants are each hosted within their own Auth0 tenant.
I think you have a single Auth0 tenant supporting multiple application tenants, and that seems right to me (since a user can be in multiple tenants).
To identify which application tenant a user is coming from, could you use the Audience parameter? Define one API per tenant and use this in a rule.
This is pretty complex. If you give more details I can try to help more.
John
Hi @john.gateley, your assessment is correct. We have a single Auth0 tenant servicing multiple app tenants.
Is there a limit on the number of APIs we can define per Auth0 tenant? We’re looking at 100s of APIs if we do one per app tenant.
More details:
- A single user could be granted access to one or more tenants
- Each tenant wants to decide what level of access that user has in the form of roles
- Each user has a default tenant which is stored in app_metadata. So, in cases where the user does not specify a tenant, we use the default. In this case its easy to determine what roles to fetch.
- When a user switches tenants - in session - or selects a different tenant to access before logging in they currently get the roles for the default tenant. This prevents us from supporting #2
- Each tenant can be identified by subdomain (i.e. .service.com) or by tenant identifier in the header. We can explore other options if it makes sense.
- The roles get added to the access token (jwt) and passed around to different backend services to identify the user and their access level. I’m not sure this is the right approach, but its the direction we’re heading now.
Hi @sjungers
I don’t know the max number of APIs, but hundreds should not be a problem.
I think what you are saying here makes sense.
John