How should you secure a multi-tenant API with Identity Server?

Question

I'm struggling with the correct way to secure a multi-tenant Web API with Identity Server. Let me explain.

We have a multi-tenant Web API that serves a ASP.NET MVC application.

• Each new customer is assigned a new TenantId.
• A customer can have multiple subscriptions of the application. Its the same as saying that the app manages multiple databases per customer (that he can access from the same base URL).
• Each user belongs to a single customer (tenant) and will have access to all that customer's subscriptions.

The API is set in a way that every endpoint includes both the tenant id and the subscription id so it can know from which subscription/database it should get the data.:

<server>/tentantId/subscriptionId/(...)

Now imagine that I have another external app (say a console app), using the client credentials flow, that is trying to access some API resource "on behalf" of a customer, meaning that will use a specific tenantId/subscriptionId pair:

<server>/1000/1/products

Every time a call hits one of the API endpoints I need to validate that this specific client app can access that tenant/subscription.

It would make a lot of sense if the Identity Server could perform that check automatically as part of the authorization flow.

If we added some way for the customer to register (consent) a specific client app to access the Web API on it's subscriptions, may be we could also set the Identity Server to know that in the form of scopes or at least include that information in the claims so that we could perform the permission check by inspecting the token instead of calling an external component.

Is this even possible? Should I try to use scopes? Claims?

Can anyone point me in the right direction?

Answer 1

Your question is confusing when you talk about multi-tenancy. Isn't an API multi-tenant by default? The way I see it, it's a resource that can be accessed by multiple users / clients.

If I understand correctly, all you want is to access the API through the MVC app on behalf of a user. In other words: a hybrid flow with API access.

Instead of putting the userid in the path, use the id from the sub claim. Which lets the API distinguish between calls on behalf of clients and calls on behalf of users.

The resource should take care of authorization. Depending on the type of authorization you can use claims. If a subscription needs to be checked then this should be done by the API, using the sub claim to distinguish the user.

Scopes on the other hand are meant to define the resource. With the scope "api1" I can access the Api1 resource (api). But it says nothing about authorization.

Answer 2

IdentityServer provides Authentication as a Service.

It is your apps' duty to provide the actual Authorization.