Challenge:
I recently helped a customer setting up OAuth 2.0 with Azure AD to protect their API backend in Azure API Management. While this Azure Doc has overall process, it uses OAuth 2.0 authorization code flow for APIM Developer Portal users to sign in and test APIs. This works great when you have applications calling APIs in an interactive manner or as the signed-in user. What if you have application(s) runs as a background service or daemon without a signed-in user that want to call APIs, for example you are using tools like Postman to test APIs. So, you need to set up client application using OAuth 2.0 Client Credentials Flow.
Solution:
Purpose of this blog is to go through how to protect your APIs published through Azure API Management using OAuth 2.0 Client Credential Flow and test using Postman. Again, use this Azure Doc to go through step 1 through 6 to complete the entire set up. If you are not interested in setting up APIM Developer Portal as Client Application, you can skip step 2, 3, 4 & 5 and follow steps below. For completeness' sake and to avoid going back and forth I'm including some of the steps from this Azure Doc in this blog.
High level steps:
Step 1: Register an application in Azure AD to represent the API
Step 2: Register another application in Azure AD to represent a client application
Register every client application that calls the API as an application in Azure AD. In this example, the client application is Postman that we will be using to test APIs.
To register another application in Azure AD to represent Postman:
Step 3: Grant permissions in Azure AD
Now that you have registered two applications to represent the API and the Postman client app, grant permissions to allow the client-app (Postman) to call the backend-app (API).
Using CLI: az ad sp list --display-name <Azure AD App Name>
Capture objectId where objectType = ServicePrincipal
In the POST URL, make sure to change {id}, this is same as resourceId from above (i.e., API App's Service Principal ID)
https://graph.microsoft.com/v1.0/servicePrincipals/{id}/appRoleAssignments
Run query. If all goes well and you got all the right Ids, you should get Created - 201 response as shown below. Check the API permission again to make sure you got the green tick mark under Status with message Granted for <tenant name>
Step 4: Configure a JWT validation policy to pre-authorize requests
Follow the instruction from the following doc to add Validate JWT policy to your API
Protect API backend in API Management using OAuth 2.0 and Azure Active Directory - Azure API Managem...
Add the following Validate JWT policy to <inbound> policy section of your API which checks the value of the audience claim in an access token obtained from Azure AD and returns an error message if the token is not valid.
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
<openid-config url="https://login.microsoftonline.com/{aad-tenant}/v2.0/.well-known/openid-configuration" />
<required-claims>
<claim name="aud">
<value>{backend-api-application-client-id}</value>
</claim>
</required-claims>
</validate-jwt>
For example, to include additional claim:
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
<openid-config url="https://login.microsoftonline.com/azurerampup.onmicrosoft.com/v2.0/.well-known/openid-configuration" />
<required-claims>
<claim name="aud">
<value>3b0bd75a-d72f-46ec-99f1-040bab17d0ed</value>
</claim>
<claim name="roles" match="all">
<value>AddRole</value>
</claim>
</required-claims>
</validate-jwt>
Step 5: Request JWT token using Postman
Now that all the setup is over, let's get JWT token first, before we make API calls
KEY |
VALUE |
grant_type |
client_credentials |
client_id |
Your client App's (step 2 from above) Application (client) ID, you can copy from Portal |
client_secret |
Your client App's client secret |
scope |
<your API app's Application (client) ID>/.default |
e. Send the request, if all goes well you should get the JWT token as shown below.
Step 6: Inspect the token (optional step)
Step 7: Make the API call
Time to call our APIs using Postman with JWT token that we got from step 5.
KEY |
VALUE |
Ocp-Apim-Subscription-Key |
Subscription key from APIM |
Authorization |
Bearer <JWT token from step 5> |
Step 8: Build an application to call the API
In this blog we used Postman to test API calls, but in Production you or your customers would build an application and implement OAuth 2.0, see Azure AD code samples.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.