In many of the business use case scenarios, we need to provide a sample client access to one of the applications hosted in Azure. But we cant simply give the access, by giving the endpoint of that application to the client. Doing this is an obvious compromise on security and we have no control over how the client is using our resource.

Fortunately, there are open standard protocols available for our disposal. One of them is OAuth 2.0 protocol which is widely used.

OAuth defines 4 ways where a client can access a resource in a protected way

1) client_credentials

2.) username and password

3.)authorization code

4.)implicit

I will limit my scope and talk about the first type:

Most of the times, the resource which we want to expose, is exposed to a trusted client. For example: there might be a Salesforce group in an organization, which needs to be access our resource. In such cases, we know the client (its trusted, as the company hired Salesforce specialists) but still we don’t want to give them unprecedented access.

In such cases, client_credentials gives us an very easy and quick way to access our resource in a secure manner.

Here is what we want to do. (taken from the following link, https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-client-creds-grant-flow):

Client credentials grant flow diagram

The following diagram explains how the client credentials grant flow works in Azure Active Directory (Azure AD).

1. The client application authenticates to the Azure AD token issuance endpoint and requests an access token.

2. The Azure AD token issuance endpoint issues the access token.

3. The access token is used to authenticate to the secured resource.

4. Data from the secured resource is returned to the client application.

Below are the steps to do it in Azure:

1.) Build your resource, which you want to expose. It might be a function, an API instance, or a Logic app or whatever. Here, we take an API instance. I am taking API instance as an example, you usually expose your resource through an API management instance in most API related architectures, which are commonly used today. Also, an API instance has inbuilt policies to validate our token. Also, we assume that there is an Azure function mounted behind the API instance.

2.) Now we create a container/application for API instance. Go to Azure Active Directory on the left hand side of the Azure portal, click App registrations.

Enter a name for the application and depending upon the client, select the required option (most of the times, it will be option 1 if you are working in a trusted setup, where different companies work for a common client) and then click Register

3.) After application is created, go to Expose an API in the left hand side and enter the API instance url in the Application ID URI setting. This would be our called application or audience. In the access token it would be the audience claim.

4.) In the homepage of Api App, you copy the Application(client) ID.

5.) Now create a second application using the App registration tab again. This would be our fictitious client application which we would use to demonstrate how client application can call our API instance. So if for example, Salesforce team needs to access our API, we need to create a container for them in Azure. Different clients will have different container, uniquely identified by client id and secret.

Lets name our client application as Client App

6.) After Client App is created, we set client id and secret by going to Certificates and Secret tab. Then we click on New Client Secret and add a client secret valid for say, 1 year whose name is client_id.

Then, we copy the client secret. Also copy the client id, copy Application(client) ID as shown in the second picture.

7.) So now we have 2 applications, Api App (called service) and Client App(calling service) as below.

8.) Click On Client App, and then click Endpoints in the home page. Copy the token endpoint. This endpoint would be used by our fictitious Client App to generate token. The endpoints would be in the format as below.

The shaded blue part is the tenant id which remains constant for every environment.

9.) Now, we somehow need to tie up the Client App and Api App. This needs to be done because whenever the client needs access to our resource, he should be directed to Api App first (we assumed here, that our actual resource would be mounted behind API instance). Client should not have access any other resource. He should be authorized to access the API app only. For this thing, API instance should know what client is registered.

10.) Go to API instance and under Security Tab, click OAuth 2.0. Click on Add button.

11.) Fill the form as below. The client_id, secret and token url and the Api App ID which was copied in step 5 ,7 and 4 respectively would be used here. This is how we tie up the Api App to Client App. Copy the Api App ID into resource field as below.

12.) Now, the API management instance should validate the access token. Use the following Validate-jwt policy to validate the access token.

<validate-jwt header-name=”Authorization” failed-validation-httpcode=”401" failed-validation-error-message=”Unauthorized. Access token is missing or invalid or expired.” require-scheme=”Bearer” require-expiration-time=”true” output-token-variable-name=”jwt”>

<openid-config url=”https://login.microsoftonline.com/<tenant_id>/.well-known/openid-configuration" />

<audiences>

<audience>https://sampleapimgmtinstance.azure-api.net</audience>

</audiences>

<issuers>

<issuer>https://sts.windows.net/<tenant_id>/</issuer>

</issuers>

</validate-jwt>

Use it as below:

13.) Create 2 Postman requests for the below 2 scenarios:

- Our ficititious app, Salesforce will use this request to get access token

- The generated access token in the first request, will be used to call the API instance, which in turn will call our required resource.

Here are they:

First request:

Second Request:

Authorization will have the value: Bearer access_token (Access_token is the one we got form the first request).

Ocp-Apim-subscription-Key is the susbscription key, when the API is published in a product.

The validate-jwt policy validated the access token, if you pass the wrong token, you will get the below error

Unauthorized.Access token is missing or invalid.

The access token is valid for 1 hour, and this token can be used by clients as longer as it does not expire. In this way, your clients have limited access to the resource and not unprecedented access.

Please feel free to post comment or improve this article.

Feedbacks are appreciated :)

My next article is on the Amazing Azure Key vault:

https://medium.com/@raunaknarooka/dont-spill-out-your-secrets-use-azure-key-vault-576128cdb986?source=friends_link&sk=ce546a19758d8a5afb52fdceba6fff65