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.
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.
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).
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
Copy the v2 URLs for the Authorization and Token endpoints as per the image below:
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.
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:
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 (9)
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.
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
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?
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.
Thank You.
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.
I tired locally and on the deployed dev site but I'm still getting that HTML response.
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.
Thanks, but the screenshot only captured the start of some values (which I suppose is most problematic for fields 4 and 5).