A Comprehensive Guide to Implementing OAuth Token Security with AzureAD as a Client Provider

“Guard your data fortress with API security: Your Key to Peace of Mind.”

Overview

In today’s digital landscape, where applications and services interact seamlessly, ensuring robust security measures is paramount. OAuth Token Security has emerged as a popular solution for securing API endpoints and protecting sensitive data.

The guide begins by laying a solid foundation for understanding OAuth, its core concepts, and how it works. It then dives into the specific role of AzureAD as a client provider in the OAuth framework and highlights its security and identity management benefits.

Prerequisites

• Anypoint Platform credentials and admin access.
• Credential and Admin level access to Azure AD
• MuleSoft application created and published to exchange.

Setting up Azure AD

• Log in to Azure AD and go to Active Directory.

From the Active Directory, navigate to App registrations.

Select “New Registrations”. Here we will register MuleSoft as an app. This will help us generate the necessary information to add Azure AD as a Client Provider in the Anypoint Platform.

Fill in the details to create a new registration and then click register. You can name the registration as per your liking. Under Support Account types, select “Default Directory only — Single Tenant”.

Once the registration is complete, you will see the Client and Tenant Id displayed in the app. Copy these values and keep them handy.

Click on endpoints to copy the WS-Federation sign-on endpoint. This will be the issuer id in the Client Management configuration.

To find the value of the Client Secret, navigate to “Certificates & Secrets” from the left panel in the registered app and copy the secret value. Note: The value of the secret is only shown once, so copy it and store it safely.

Now we need to add permissions to the app we just registered. Navigate to “add permissions” from the left panel and grant Read and Write permissions to the app. Write permissions are necessary so Anypoint Platform can create the API in Azure AD when we implement the security. These permissions can be modified once the APIs are created.

Click on Grant admin access for the directory to finish.

Setting up Anypoint Platform For Client Providers and Env Settings

• Go to your Anypoint platform and navigate to Access Management.

Under Access Management, select Client Providers> Add Client Provider> OpenID Connect for Azure.

Fill in the required values from the details we stored from Azure AD. Click save to create. This creates a configuration under the Client Provider page.

Now we need to set up the desired environment to pick up the Client Provider we just set. To do so, navigate to the “Environment” tab from the left panel and select the desired environment. Here we will see an option to set the Client Provider, from the drop-down menu select the client provider we just set up.

Client Provider set up along with environment settings is complete. Now we will move on to implementing the OAuth policy.

NOTE: The OAuth policy is not visible unless a Client Provider is set up. If you have already set up an API instance, this policy will not be visible. Ensure that the API instance for your API is set after the Client Provider has been configured.

Adding OAuth Policy to APIs

Start by navigating to the API manager and adding an API. Please follow the steps from my previous blog if you need help setting up an API instance. Once the API is created, you should see something like below.

Click on Policies from the left panel and select “Add Policy”.

From the categories, select the OpenId Connect access token enforcement policy and apply it.

Navigate back to “API Summary”. On the top-right side of the screen, you will see the “Actions” menu. From the drop-down, select “View API in Exchange”.

Now we need to request access for our consumers to access this API.
Select “Request Access”. Here select “create new application” and add the details as follows. It is necessary to select an OAuth 2.0 Grant type. In this case, we have selected the Implicit Grant. We also need to give the OAuth 2.0 redirect URIs, this URI will be the URI of your application.

Click on “Create” and then on “Request Access”. If you had given your registered app the read and write accesses in the steps above whilst setting up Azure AD, then you should see Client ID and Secret displayed on the screen. Remember to save this information for later.
NOTE: In case of any error, ensure that the app registered in Azure AD has the right permissions.

To ensure that the request has been granted and the client provider setup was complete, we can navigate back to Azure AD. Under app registrations, we will see the same app will be created.

Setup up Request calls to MuleSoft API

If we try to hit our MuleSoft API endpoint, we will see an error “Access token was not provided”.

To get the OAuth token, we need to make a request call to Azure AD. To make the call we use the following details:
- authorize url: https://login.microsoftonline.com/2ef0fdd8-0331-4add-9b70-e75b36b636a9/oauth2/v2.0/token
- token url: https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token
- client id: {your client id}
- client secret: {your client secret}
- scope: https://graph.microsoft.com/.default
- grant_type=client_credentials

Following is a cURL command for the request:

curl --location 'https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id={your client id}' \
--data-urlencode 'client_secret={your client secret}' \
--data-urlencode 'scope=https://graph.microsoft.com/.default'

The response from the request will have “access_token” which should be used to send the request to the MuleSoft API.

Use the access token received from the token request for the Authorization Bearer token to send the request.

Conclusion

If you already have Azure AD, it can be beneficial to use the same as a client provider to authenticate the calls to MuleSoft APIs. In case, any other system is calling or interacting with the MuleSoft API which has OAuth Policy applied, we can use caching mechanism to reduce the number of calls to the client provider and increase efficiency. The same can be done for calls made between MuleSoft apps. Check the blog here to learn how we can implement caching strategies in MuleSoft. To read more on client ID enforcement policy in MuleSoft or OpenID Connect OAuth 2.0 Token Enforcement Policy, refer to the links.