Authorization Approach for Multiple Web API Providers

Azure Active Directory (Azure AD) is a popular enterprise identity service used by many organizations for enabling single sign-on for applications and protect their web APIs.

Version 2.0 of Microsoft Identity platform (aka Azure AD) is the latest and improved implementation of OpenId Connect (OIDC) based authentication and OAuth 2.0 authorization flows.

If you are interested in achieving the following requirements for your application using Azure AD, then this article should serve as a guide for you:

1. Enable single sign-on (OpenId Connect authentication).

2. Protect web APIs using OAuth 2 authorization (Implicit Grant flow).

3. Consume multiple web API providers from single client application.

For our purposes, let’s assume our client application has a Single Page Architecture (Angular SPA) which needs to consume two different API providers:

1. Microsoft Graph API — to fetch employee’s profile details and display them in an application GUI. A single access token will be obtained and submitted with a Graph API call.
2. Custom web APIs — for the application’s functionality and data. Another (single) access token will be obtained and submitted with each web API call. 

Users of the application must be authenticated (OIDC) using Azure AD before being allowed to access functionality and data protected by APIs. A valid JWT access token needs to be passed for accessing protected APIs.

You may also like: Backend Web API With C#: Step-by-Step Tutorial.

Perform SPA Application Registration in Azure Portal

As a first step, register your client application (SPA) in the Azure portal. Mention the redirect URIs for your SPA application and select both ID tokens and Access tokens for implicit grant OAuth 2 flow.

Please see the screenshot of this step for the hypothetical web application:

Expose Web API in Azure Portal

Define the following configurations for web APIs.

1. Define custom scopes for web APIs to control access to functionality protected by API.

2. Authorize client applications that can call web APIs without requiring the user to provide consent during invocation.

Specify API Permissions for Client App in Azure Portal

Select all permissions that the client application should have to call APIs. To get the user’s profile, select Microsoft Graph API with User.Read scope. Also, select web API and custom scopes.

Please see the screenshots below:

Invoke Microsoft Graph API From Angular SPA

Our Angular SPA invokes the Graph API to fetch a user's profile details. You can use any of authentication client library in your Angular app:

• angular-auth-oidc-client.

• oidc-client

An important point to note here is that Microsoft Graph API and custom web APIs are two different API providers, so their scopes cannot be clubbed together into a single Azure AD authorization call from within the Angular app. The right approach has to be two separate calls (i.e. one call for each of Microsoft Graph API and web API, specifying different scopes for each).

The sequence of steps for consuming Microsoft Graph API are as follows:

1. Specify User.Read scope for your first call from Angular to Azure AD OAuth 2.0 authorization endpoint.

        2. User authentication is performed by Azure AD.

        3. Azure AD generates access token with permission to invoke Graph API for the user’s profile                      details. It also generates an ID token, indicating user sign in.

        4. Note that Azure AD in v2.0 internally invokes userinfo Graph API to fetch and return user                        details, but only basic user attributes. We can later make an explicit call to another Graph API                    endpoint for fetching detailed attributes of the user.

        5. Grab this access token in the Angular code from the Azure AD redirected request and invoke the                Graph API with this access token set as Bearer token in the Authorization header. This should                  return the user's profile details, such as employee number, photo, and org hierarchy.

Below is an example that shows the HTTP GET request to the Graph API endpoint to obtain the user's employee number. Please note that the Bearer token should be passed in the Authorization header in the request.

xxxxxxxxxx

https://graph.microsoft.com/v1.0/me$,userPrincipalName,country,extension_8b4e685f580748b59864d62c2e7fcfad_employeeNumber

Invoke Custom Web API From the Angular SPA

The sequence of steps are as follows:

1. Specify the http://mystatementapi/access_as_user scope. (This scope can be anything but should match whatever is defined during the app registration process in the Azure AD portal.) This will be used for your second call to the Azure AD OAuth 2.0 authorization endpoint.

2. Note that user authentication will NOT be performed again, as the authentication cookie should have been set in browser from the earlier call.

3. Azure AD generates another access token with permission to invoke web APIs. We will use this token for each web API.

4. Grab this custom API access token fromt the Angular code from the Azure AD redirected request and then invoke your web API with the access token set as the Bearer token in Authorization header.

5. The web API will validate the token from Azure AD and return a response for successful validation or error in case of failure

Refresh the Access Token

Access tokens are short-lived entities. Token expiration time is configurable but generally set to be an hour or less. Before expiration of the token, the client application should request a new access token from Azure AD. This should be done in the background without user involvement. A hidden iframe approach can be used in the client application for this purpose.

This is really needed for access tokens used for the invocation of a custom web API and not for the Graph API from this example.

Summary

This article should help in clarifying the design approach and practical steps to achieve OAuth 2 authorization for different web API providers from an Angular client application.

Azure AD functions as Cloud-based Identity Service for authentication and authorization of your applications deployed on any cloud (not only Azure cloud) or on-premise datacenter. 

You may want to use a Postman client to test and verify your Azure AD configurations and web APIs, even before writing a single piece of code in the Angular application.

Further Reading

• Authentication and Authorization: Mastering Security.
• Four Most Used REST API Authentication Methods.
• RESTful API Authentication Basics.