This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses securing the backend WebAPI for multitenant solutions.

A backend WebAPI can manage CRUD operations on resources. The frontend web application sends an HTTP request to the Web API and it returns a JSON response to the caller. There are no anonymous requests  so the web application must authenticate using say OAuth2.0 Bearer Tokens. Since we are considering a server to server scenario, the calling application does not make any AJAX calls to the API from the browser client. There are two main approaches to handle this for a multitenant application.

First, a delegated identity for the user could be  used where the web application authenticates with the user’s identity. 

Second, the application authenticates with its credentials such as its client ID for an OAuth token requested via client credential flow.

The differences between the first and the second  are quite a few. With Delegated user identity, the bearer token sent to the Web API contains the user identity. The Web API makes authorization decisions based on this identity. The web application needs to handle errors from the Web API when the user is not authorized to perform an action. The authorization decisions from the web application will impact the visibility of certain user interface elements. The WebAPI can potentially be used by untrusted clients.

With the ApplicationIdentity, the web API does not get information about the user. The web API cannot perform any authorization based on the user identity but it cannot be used by an untrusted client. The approach may be somewhat simpler and more maintainable because there is no authorization logic.

The credential in both these cases involves an access token. Azure AD can issue token based on memberships to the Active Directory.

The Web API must be registered with the Azure AD. The client ID of the web application is added to the web API application manifest. The web application must be given permission to call the web API.

The Web API must authenticate the bearer token say with the middleware that enables the application to receive the open ID Connect bearer tokens. The token can be validated in the JwtBearerEvents.TokenValidated event. The issuer is sent it the “iss” claim. Authorization can be role based and resource based. The middleware handles the authorization responses as long as the authentication scheme. This returns a 401 status code when the user is not authenticated. The web API must just specify the policy in the Authorize attribute.

A multitenant application does not control how many tenants or the direct ownership of a resource to its tenant. The customer has the complete say in this. They may want to reassign a resource to another tenant. For example, if they decide to join a machine to a different tenant, they need to disconnect from the first tenant and then register again with the new tenant.  The single sign-on (SSO) option for password hash synchronization and pass-through authentication can be used with only one Azure AD tenant.