OAuth and Multitenancy

Help
,
1

I see a lot of articles and documentation around the use of OAuth in regards to multitenant applications, but I have yet to see any supporting material for multitenancy when a user can access multiple tenants.

Put simply, if I have a UserA who belongs to TenantA, but can call API endpoints on behalf of TenantB (view data, edit data, call procedures, etc) – how is this best represented? In the access token? Some central auth store to verify access?

Note its possible for a given user to have access to 10…50…100 tenants and that this access could be revoked at a moments notice.

2

Let’s say a user can be associated with multiple tenants. Somewhere, in your backend , you have that relationship defined (e.g. “User A” has access to “Tenant 1”, “Tenant 2”, and “Tenant 3”).

If you were to have a multi tenant application in the pre-OAuth2 world, in each backend access you would ensure that the “User A” can only access those tenants that he is part of.

Now, bringing OAuth2 and its delegated authorization idea, a user gives an application consent to access their resources (i.e. “Tenant 1”, “Tenant 2”, and “Tenant 3”). Let’s start with a all-powerful token that a first-party application might get. That token would allow the application to do anything the user can do. The user would be able to choose which tenant they want to work with (like the Auth0 dashboard, for instance).

In the API, you would have some way of expressing which tenant you want to access. That could be a subdomain, a part of the path, a parameter, or a header, but this is ultimately irrelevant. Some examples:

GET https://tenant1.acme.com/api/messages
GET https://acme.com/api/tenant1/messages
GET https://acme.com/api/messages?tenant=tenant1

Where to put the tenant is ultimately irrelevant, but in every case the API would verify that the access token is valid, get the user ID (the “subject”) from the token and move on to the “business” authorization phase: is the user authorized to access the tenant? This validation is independent of OAuth2 (which gives an application the ability to do something on behalf of the user): is a validation of policies for what the user can do.

Now, if you deal with third-party apps, you might want to restrict the capabilities of the token. One way of doing so could be with general scopes (e.g. read-only access, or a subset of capabilities).

But you might also want to restrict the tenant that the token has access to. So you could have an additional scope representing the tenant for which the user allowed access to the application: e.g. tenant:all-tenants (not really all, but all the tenants of the user), and tenant:tenant-1, tenant:tenant-2 and so on.

Now, on the authorization logic of the API, after the token validation, you would also check which tenant the token is allowed to access. But, as always, after that you will need to ensure that the user (still) has access to the tenant (and thus deny access if the user removed from the tenant at a moments notice).

Not sure if I answered your question :slight_smile:

1 Like
3

There are some good points in your response @nicolas_sabena, I really appreciate it. You have the scenario down pat. What you’ve explained is exactly the problem we’re trying to solve here.

With that said, I’m a little fuzzy on this part:

The crux of the whole problem above is should that tenant access we’ve been talking about be on the token itself, i.e. should the APIs introspect an access token to verify that the user has access to make a request for that tenant (via the querystring, path, wherever it is) or should that be the responsibility of the API itself.

Your quote sounds a little like it’s beyond the scope of OAuth2 and maybe it should not be there, but I could be misunderstanding. Or maybe it is beyond the scope, but is acceptable.

Thanks again for the response

4

The original intent of the OAuth2 protocol is about delegated authorization, and scopes is the device intended to carry information about what exactly is it that the user is delegating. But basic authorization controls still need to happen outside the OAuth2 token. That’s the theory, at least, but some people certainly misuse or abuse the tokens to carry more generic authorization information.

Vittorio Bertocci talks about this at length in this great blog post: On The Nature of OAuth2’s Scopes. Hope that helps!

1 Like