Introduction

The Microsoft Authentication Library (MSAL) enables developers to acquire tokens from the Microsoft identity platform in order to authenticate users and access secured web APIs. It can be used to provide secure access to Microsoft Graph, other Microsoft APIs, third-party web APIs, or your own web API. MSAL supports many different application architectures and platforms including .NET, JavaScript, Java, Python, Android, and iOS.

MSAL gives you many ways to get tokens, with a consistent API for a number of platforms. Using MSAL provides the following benefits:

Why MSAL is important here?

We have been trying to include user’s role in access token because our web APIs are protected with roles. Unfortunately we were not able to include it in user’s access token. There is no any documentation which says why roles are not included in access token especially while working with Authorization code flow (SPA or web app). This article will guide the user about necessary steps to be taken while configuring the app in Azure AD.

How to configure apps in Azure AD?

In this example, a SPA (ReactJS app) implement authentication and will use a second ASP.NET Core application which implements the resources API. Two Azure AD App registrations are created for this, one for each application.

First of all, we need to register two apps in Azure AD. First one is the Client app named “AzureAD-Client”, which is used by our SPA or Front-end app and we request an access token for this app. Second one is the Web Api app (REST APIs) named “AzureAD-WebApi” which is our resource server and it’s endpoints are protected with roles.

App roles are added to the App registration for the WebApi. These roles are used in the WebApi server application which are returned in a access token, depending how your client implemented the OIDC standard.

Two roles are added to the Azure AD App registration for the API. These roles are for the API and will be added to the access token if the identity has been assigned the roles in the enterprise application of the Azure AD directory. The roles could also be added directly in the manifest.

App roles

This App registration exposes an API and defines roles for the API project authorization. An access_as_user scope is added to the Azure App registration which is a delegated scope type.

expose an API

Apply roles in Azure AD enterprise applications

The new roles which were defined in the Azure AD App registration can now be used. This is setup in the Enterprise application blade of the Azure AD directory. In the Enterprise application list, select the App registration for the API. New users or groups can be added here, and the roles can then be assigned.

User and roles in enterprise applications

The API permissions are setup to include the scope created in the API Azure AD App registration. The standard OIDC scopes are added to the registration. All scopes are delegated scopes. Now we need to add permission/scope of AzureAD-WebApi into permission of AzureAD-Client app.

api permissions

Now all the setup is ready and AzureAD-Client app will be used to get access token for both client and server.

Note: we need to specify our scope i.e. access_as_user in example while requesting access token. Although make sure “User.Read” scope shouldn’t present on the list of scope, it doesn’t allow roles to be added in access token. We don’t why but it could be bug and not documented anywhere.

SPA app code sample

azure ad token request

References

https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-overview

Implement app roles authorization with Azure AD and ASP.NET Core


https://stackoverflow.com/questions/71053269/scope-is-not-being-added-to-access-token-returned-from-azure-ad

Leave a Reply

Your email address will not be published. Required fields are marked *