Azure AD Bearer Token For Multiple WebApi Endpoints?
You have two options:
- Get two tokens
- 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.
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.