Multi tenant database behind API, need to identify the user/tenant

Help
,
1

We are running a multi-tenant database behind an auth0-protected API on Azure (all ASP Net Core). When the user calls the API (for example using a server side app) in order to retrieve data, we need to ensure that only the data belonging to the users site/organization is returned (i.e. "… where tenant = ‘example.com’) and never the data belonging to other customers.

Our customers/tenants are companies each having multiple users. Currently we are doing skunk work and the tenants are simply identified by their domain name e.g. “example.com” which is part of the user name. All “user management” (e.g. roles) is in the metadata, we do not run any kind of user management wihin our applications so far.

Unfortunately we only get the Auth0 user-id from the access taken which is not sufficient to identify the tenant.

So far I looked into the following to resolve the issue:

  1. Web Hook (client credentials exchange). The idea was to inject the user name (as claim/scope) into the access token but my impression (judging by the examples) is that the user information cannot be accessed from within the hook.

  2. Getting the user info within the API. That would most likely work but (a) Auth0’s documentation advises against retrieving the user info for each request due to Auth0’s rate limit and (b) this would probably increase the latency.

Currently I only see two ways to resolve this:

  1. Use a custom database which is something I would prefer to avoid. I also do not know whether Azure Sql is supported and whether a custom database is supported by the free plan (as we are still doing skunk work).

  2. Implement a lookup associating Auth0’s user-id and user-name. Somehow this does not feel right and I am afraid of security loop-holes. Also this might eventually break and go out of sync when the tokens expire.

Any ideas?

2

I think custom claims could help you out here.

The docs above are for the ID token, but will work just fine for the access token as well. Basically you can add add a claim like http://example.com/tenant that contains the name of the company/tenant that the user is allowed to access. The way to add custom claims is through rules.

Keep in mind that to be OIDC conformant, you need to namespace your custom claims. That’s why I put http://example.com/ in my example.

1 Like
3

Hi thijmen96,

thanks a lot for your reply.
This looks kind of promising (and really simple). I was not aware that custom rules also apply to access tokens (I am already using them for roles in the id token).
Unfortunately I do not have the time to verify this right now, but will update the thread in the next days.

4

Perfect!
This was exactly what I needed and your reply probably saved me two weeks of implementing a worse solution.
All I needed to do was adding a single line in my existing rule:

context.accessToken[‘https://example.com/tenant’] = user.email.split(‘@’)[1] || {};