Azure AD Bearer Token For Multiple WebApi Endpoints?

Question

We're using Angular, .Net WebApi, and Azure to build out several applications. And what we've been doing is securing the applications through Azure AD via the implicit oAuth2/OIDC grant flow.

Things are working well, but we have had a simple architecture so far. IE 'Front End App1' -> 'WebApi App1'

When we request the token to AAD we send the resource (Application Id for 'WebApi App1') in the token request. It seems this is a required property in the token request. How does this scale out?

Say we have a situation where 'Front End App1' needs to talk to 'WebApi App1' and 'WebApi App2'. Do we need to make multiple token requests? What do people do in these situations in Azure? It seems wonky to tightly couple a bearer token to one resource.

It seems that another approach is that I can have both the api apps configured to validate tokens for the same Azure tenant and application Id. That way the token is good for either apps, but that isn't very flexible either as that would mean all tokens for either app are good for the other...

Answer 1

You have two options:

1. Get two tokens
2. Use the same app id for both APIs

Getting a token per API is the normal approach.

A bearer token in Azure AD is always only valid for one API. It can contain scopes/roles of the calling user/app on that API, and those values are simple strings defined in the app manifest, e.g. User.Read. Those values can overlap between APIs, and thus we cannot have a token valid for two APIs.

Answer 2

Problem Statement: How to call multiple WebApi using same token from UI application.

My Solution:

Let there be two Web-Api, WebApi01 and WebApi02. In Azure AD, instead of registering two Applications, I registered just one Application, say MasterAPI. Also, the client application ie UI app has to be registered, as usual.

The MasterAPI is not an actual application. So, there might not be any redirect URL, neither we need any. In this API, we declare two scopes, to start with, for each of the WebAPI (WebAPI01 & WebAPI02). I usually follow a nomenclature like App.Feature.Verb etc. So, the scopes names will be something like Master.WebAPI01.Read and Master.WebAPI02.Read.

They will be exposed like api://MasterAPI-Application-Id//Master.WebAPI01.Read and api://MasterAPI-Application-Id//Master.WebAPI02.Read in azure application registration page.

During Access-Token request, I pass these two scopes to Azure AD endpoint. The response I get contains the scope claim (scp) with the value "Master.WebAPI01.Read Master.WebAPI02.Read".

"scp":"Master.WebAPI01.Read Master.WebAPI02.Read"

This way I am telling to system that the trusted Client-UI application has a token with accessibility to two features. Simply put, whoever can log into the Client Application, will have access to both the features. An Authenticated user is now authorized to use two features.

This can be further restricted. Say, I, the admin, should have control over who can access what. For that, I had to implement Role based access control (RBAC). I defined Custom made Application roles in the MasterAPI. This can be done by manipulating manifest.

Now, when I receive access token, I get the roles claim with the value set. The value depends on what roles are assigned to the user.

"roles": [ "Access_WebAPI01", "Access_WebAPI02" ],

The token is passed to the resource WebAPI (in this case WebAPI01 or WebAPI02) via header.The receiver WebAPI then parses the header token to check whether required role exists or not.

So, in nutshell, Scope and RBAC combination works for me. And I do not have to hit database for Authentication and Authorization.

In case a new feature is added, say, WebAPI03. All I need to do is Set up the scope in MasterAPI. and Either use existing roles or assign a new role to the user.

PS: Why MasterAPI? In Azure AD, all the scopes has to be from one resource only.