Access Management with Azure Active Directory Application Roles in SPA

Access Management with Azure Active Directory Application Roles in SPA

by 2 Comments


This article will try to give you a hands-on impression from utilizing Azure Active Directory in a web application and is accompanied with a basic solution example on Github.

Please feel free to utilize it as you wish and contribute your modifications to our Github repository:

Azure Active Directory Application Roles

Azure Active Directory (Azure AD) is Microsoft’s cloud based directory, offering a comprehensive identity and access management solution that provides a robust set of capabilities to manage users and groups.

Application developers and Software-as-a-Service (SaaS) providers can develop cloud services or Line of Business applications (LoB) that can be integrated with Azure Active Directory (Azure AD) to provide secure sign in (authentication) and authorization (role/group based) for their services.

Azure AD offers developers the ability to declare a set of roles as part of the application registration in Azure AD. Once the roles have been declared, when a customer admin assigns users/groups to the application in the Azure management portal, they select which application role the user/group is assigned to. When a user gets assigned to an application role (either through a direct assignment or via an assignment to a group that the user is member of), Azure AD includes the roles claim in the token while the user signs in to the application. The application can then authorize the user using constructs like IsInRole("writer") or the [Authorize (Roles="Editor")] attribute.

To integrate an application or service with Azure AD, a developer must first register the application with Azure AD via the Azure portal.

Azure Active Directory Application Registration

Any application that outsources authentication to Azure AD must be registered in a directory. This step involves telling Azure AD about your application, including the URL where it’s located, the URL to send replies after authentication, the URI to identify your application, and more. This information is required for a few key reasons:

Azure AD needs coordinates to communicate with the application when handling sign-on or exchanging tokens. These include the following:

  • Application ID URI: The identifier for an application. This value is sent to Azure AD during authentication to indicate which application the caller wants a token for. Additionally, this value is included in the token so that the application knows it was the intended target.
  • Reply URL and Redirect URI: In the case of a web API or web application, the Reply URL is the location to which Azure AD will send the authentication response, including a token if the authentication was successful. In the case of a native application, the Redirect URI is a unique identifier to which Azure AD will redirect the user-agent in an OAuth 2.0 request.
  • Client ID: The ID for an application, which is generated by Azure AD when the application is registered. When requesting an authorization code or token, the client ID and key are sent to Azure AD during authentication.

To register a new application in the Azure portal sign in to the Azure classic portal, click on the Active Directory icon on the left menu, and then click on the desired directory. On the top menu, click Applications. If no apps have been added to your directory, this page will only show the Add an App link. Click on the link, or alternatively you can click on the Add button on the command bar.

On the “Tell us about your application page”, you must specify a name for your application, as well as indicate the type of application you are registering with Azure AD. You can choose from a Web application and/or Web API (default, known as a confidential client in OAuth2 parlance) or Native client application which represents an application that is installed on a device such as a phone or computer (known as a public client in OAuth2 parlance). Once finished, click the arrow icon on the bottom-right corner of the page.

 Azure Active Directory Application Configuration

On the App Configuration tab, opt to default settings for "Application is multi-tenant" and Yes for "User Assignment required to access app" settings, provide the Sign-on URL and App ID URI, for your Web application, then click the button save.

Declaring application roles for your application
Either the application owner (developer of the app) or the global administrator of the developer’s directory can declare application roles for an application. While still on Applications configuration tab menu, at the bottom of page find and click the action “Manage Manifest”, and download the Application Manifest file.

Application manifest file has to be changed locally and uploaded again on Azure server.

Click to open the application for which you wish to enable declare application roles. Click on the Manage Manifest action button on the bottom bar and select to Download Manifest. Open the manifest file in a JSON editor of your choice, change flag “oauth2AllowImplicitFlow” to true, and add application roles as described below:

"appRoles": [
      "allowedMemberTypes": [
      "description": "Writer can write and edit its own blog post.",
      "displayName": "Writer",
      "id": "915C5C81-E801-408F-A138-9541FBD30697",
      "isEnabled": true,
      "value": "Writer"
      "allowedMemberTypes": [
      "description": "Editor can edit and publish blog post",
      "displayName": "Editor",
      "id": "9FC3EB8E-156F-4C32-8990-983119FD6226",
      "isEnabled": true,
      "value": "Editor"
      "allowedMemberTypes": [
      "description": "Admin performs system wide actions.",
      "displayName": "Admin",
      "id": "2993D02E-44FE-4A17-9DC5-B54CE45CADE0",
      "isEnabled": true,
      "value": "Admin"

Save just edited manifest file and while still on application tab, at the bottom of page click the button “Manage Manifest” and opt to Upload Manifest.

Browse for manifest file you just edited and upload it.

Assigning users and groups to application roles

After a global administrator of the customer’s organization has installed your application, either they themselves or a user accounts administrator in their organization can then assign users and groups to your application: navigate to the Users tab under the application to which you would like to assign users and groups. Select a user and click on the Assign action on the bottom bar. Here you can assign the desired role to the user.

Single Page Application (SPA)

This blog post describes authentication for a Single Page Application (SPA) that uses Azure AD to secure its Web API back end. Single page applications are typically structured as a JavaScript presentation layer (front-end) that runs in the browser and a Web API back-end that runs on a server and implements the application’s business logic. In this scenario, when the user signs in, the JavaScript front-end uses Active Directory Authentication Library for JavaScript (ADAL.JS) and the OAuth 2.0 Implicit Grant protocol to obtain an ID token (id_token) from Azure AD. This token is cached and the client attaches it to the request as the bearer token when making calls to its Web API back end, which is secured using the OWIN middleware.

ADAL & AngularJS

Front-end application part is based on ADAL and AngularJS. Active Directory Authentication Library for JavaScript (ADAL JS) helps us to use Azure AD for handling authentication in our single page application. This library is optimized for working together with AngularJS.

All client side dependencies are managed by Bower ( ) and run by Gulp ( ) .

Bower is a package manager. It's good at, well, managing packages — anything that we depend on an external author for. Good examples are CSS frameworks like Bootstrap, libraries like jQuery, jQuery plugins, or JavaScript frameworks like Angular.

There are a lot of tasks involved with creating and deploying a front-end application. Gulp is a task runner tool that simplifies common tasks to include things like watching file changes, concatenating/minifying files, prefixing files for different browsers, and linking JavaScript.

The image below depicts configuration of ADAL AuthenticationServiceProvider, whose configuration actually points to Azure AD, under which the app is registered.


The back-end side of this application is based on Web API 2 and OWIN middleware. Web API controllers expose end points for front-end to communicate with, while OWIN middleware is configured with Azure ActiveDirectory BearerAuthentication options.

Role Based Access Management

User authorization is part of the Web API controllers. Each is decorated with AuthorizeAttribute with provided Role that has access to desired functionality.

The call passes from the front-end through OWIN middleware, which populates the ClaimsPrincipal object with data taken from token passed along with that call.

The collection of claims is extracted for “RoleClaimType” equal to “roles”, and utilized by the AuthorizeAttribute to validate the user role. If the role is present, call to action will succeed, if not, “401 Unauthorized” error will occur.


Authentication Scenarios for Azure AD

Integrating Applications with Azure Active Directory

Azure Active Directory Authentication Libraries

Sample solution on GitHub


Srdjan Markovic

Passionate Software Architect with 10+ years of experience in implementation complex solutions, primarily based on Microsoft technologies.


  • Gravatar Image

    If I want to deploy my SPA (ADAL JS for Authentication) and WEB API(Role based Access ) service on different domains then how can I achieve this ? should I need to register two different app's in Azure AD ?

  • Gravatar Image

    Yes. You have to register both applications in Azure under same Active Directory (AD). Further, the Web API has to be configured to expose a set of permissions, which are used to limit the web application’s access to its resources, which can be managed from the “Permissions to Other Applications” drop-down menu in the Azure Management Portal. And finally, of CORS, you have to enable CORS for your Web API, to accept requests from another domain.
    More about Web Application to Web API:
    More about CORS:

Leave a reply

Comment sent for approval