DEV Community

Christos Matskas for The 425 Show

Posted on

Calling an Azure AD secured API with Postman

Secure APIs are all the rage, but how can we easily test them. If you're using Postman, then this blog post will show you how to configure and use Postman to call an Azure AD-secured API.

The secure API expects an access token to be passed. Therefore, Postman needs to acquire and use an Access Token when calling the API. If there is no token attached to the request, then you'll most likely receive an HTTP 401 error (unauthenticated) - which is right. If you pass an Access Token with your request but don't have the right scope, if your API has been coded correctly, you should receive an HTTP 403 error (unauthorized) - which is also right. Let's see how we can test our APIs with Postman!

Configure the App Registration for Postman

In order for Postman to be able to acquire an Access Token, it needs to have a corresponding Azure AD App Registration. In this section, we'll configure the App Registration in Azure AD. If you don't have an Azure AD already (I doubt it since you're reading this), you can get a FREE, full-blown P1 Azure AD Tenant through the Microsoft 365 Developer Program.

Sign in to your Azure AD portal, navigate to App Registrations and click on the + New Registration button. Give the app a meaningful name and press Register.

Alt Text

Then, open the Authentication tab and Add a platform. Select Web for the platform. In the Redirect URI add the following https://oauth.pstmn.io/v1/callback and then press Configure.

Alt Text

We also need a client secret. Navigate to the Certificates and Secrets tab and create a new secret. Make sure to copy the secret value as it will be unavailable once you navigate off this tab (but you can always delete it and recreate it).

Alt Text

Information needed for Postman

  • Client Id: Can be found in the Overview Tab
  • Client Secret: Was created and copied in the previous step
  • Auth URL: In the Overview Tab, click on Endpoints
  • Access Token URL: In the Overview Tab, click on Endpoints
  • Scope: e.g api://279cfdb1-18d5-4fd6-b563-291dcd4b561a/weather.read

You can find the right scope in your API App Registration in Azure AD -> open the Expose an API tab -> Copy the Scope

Alt Text

Copy the v2 URLs for the Authorization and Token endpoints as per the image below:

Alt Text

Configure Postman

We now have everything we need to configure our Auth settings in Postman. In your Postman, create a new Request and navigate to the Authorization tab. Next populate the fields as shown in the image below, using all the settings we gathered in the previous section.

Alt Text

Note: you'll need to check the Authorize using browser checkbox and ensure that your browser is not blocking any popups.

We are now ready to test our configuration. Press the Get New Access Token in Postman. If everything's configured correctly, you should see something similar as per the video below:

Alt Text

You can now use Postman to call various API endpoints. Note that if you need different scopes for different parts of the API, you'll need to add them to the scopes which will need to be space delimited.

Have fun securing and testing your APIs and make sure to join our Discord if you have any Identity or Azure related questions.

Top comments (10)

Collapse
 
buffalonian profile image
Buffalonian

How do you avoid this login screen authorization non-sense at the application layer? I thought B2B web-app -> API secured calls with AD should be doing this all behind the scenes. It seems lame to do the pop-up and making it feel like 1999.

Collapse
 
christosmatskas profile image
Christos Matskas

In order to call an API you need to consent to the appropriate permissions. As a user, this is important because you need to verify what the application is trying to access. There are ways to avoid the consent by using an Admin to consent on behalf of the whole org (usually in B2B,SaaS applications). This way, a web app can acquire tokens for an API silently without prompting the user...It's all about security

Collapse
 
superjb profile image
super-jb

I had the same question. Not so much in regards to reduce the number of user steps, but in terms of implementing automated testing on your WebApp / WebApi.
Ex: integration testing a given Api where there are restrictions on who can see what or read/write permissions per user.
If I'm building an automated test to assert UserA and update a value and UserB can't, how does one circumvent the confirmation screen and just get the aothToken for the given user?

Collapse
 
keithlawless profile image
keith-lawless

Thanks for the writeup. The only change I had to make was dropping the "api://" from the Scope in Postman. I was getting an "invalid aud" error from Azure since it was deriving the Audience from the Scope, and didn't like the "api://" as part of the Audience.

Collapse
 
drethedevjs profile image
Andre Thomas

Does this solution work for debugging locally? When I start debugging in VS and hit the endpoint, I get a HTML response with "Sign in to your account" in the title tags.

Collapse
 
drethedevjs profile image
Andre Thomas

I tired locally and on the deployed dev site but I'm still getting that HTML response.

Collapse
 
gonzaleski profile image
Arad Soutehkeshan

Hi Andre,
I wonder if you have found a solution to this as I am facing the same issue.
Thanks.

Collapse
 
hybridtechie profile image
Nithin James

Thank You.

Collapse
 
chealer profile image
Philippe Cloutier

There is no need to use Authorization Code. I don't know if that is actually possible, but we managed to authenticate using Grant Type Client Credentials instead.

Collapse
 
chealer profile image
Philippe Cloutier

Thanks, but the screenshot only captured the start of some values (which I suppose is most problematic for fields 4 and 5).