There are cases that your APIs need to support both user and service-to-service bearer tokens. With this requirement, your API endpoints will have to support mutiple authentication schemes and should validate different JWT token (
access_token) formats from different authority/issuers. An
access_token could could come from a mobile, a web browser or SPA application after a user has been successfully logged in, or it could come from a service/deamon application that uses a Client Credentials flow to obtain a token.
The Client Credentials flow is typically used for server-to-server scenarios, when interconnected internal applications within a system need to authenticate without a login form to present username and password. With this approach, you need a
client_secret and a
scope in exchange for an
access_token to access an API endpoint (a.k.a protected resource). Check out my previous post on how we can obtain an access token with Client Credentials flow using Postman here: Testing Web APIs with POSTMAN and Automating Bearer Token Generation
The User flow, or in other terms, user-initiated action is typically referred to as the "Implicit" flow whereby mobile and browser-based apps immediately grant the user an
access_token in order for the application to access your protected API endpoints. However, the "implicit" flow is the old way to allow authorization from browser-based applications. Nowadays, the Authorization Code flow (with PKCE - Proof Key for Code Exchange) is the new standard and the recommended approach for attaining a more secure authorization for these types of applications.
We won't dive deep into the details about PKCE in this post and I would recommend you to read this article from Postman Blog instead:
In this post, we will take a look at how we can use Postman to obtain an access token from a user initiated flow that's configured in Azure B2C without having you to create test application for you to login. The main goal is to be able to test your protected APIs easily without creating an web application for you to login and obtain an
The request parameter requirements
You must obtain the following parameters before moving forward:
- Authorize Url - This is the endpoint to initiate an authorization to Azure B2C. The format would be something like:
SignUpSignInPolicyIdis typically the user flow name which can be found at the User flows section in Azure AD B2C.
- Token Url - This is the endpoint for requesting a token from Azure B2C. The format would be something like:
You can obtain both endpoints from
.well-known/openid-configuration endpoint. For example navigating to:
- Redirect Url - The redirect Uri for SPA application configured in Azure B2c App Registrations for your API application. Your API application account type must be configured for authenticating users with user flows. Take a look at the following screenshots for your reference:
- ClientId - The Client Id of your API application registered in App Registrations. This is typically a
- Scope - The scope configured for your API application. You can find it under the "Expose an API" section within your API application registration. The scope format would like something like:
Making a token request from Postman
At this point, you should now have the required parameter values with you. Now, in Postman, add/open a new tab and then switch to Authorization tab as shown in the following screenshot:
OAuth 2.0 from the Type dropdown and you should be presented with the following form:
The preceding screenshot is the section for configuring a new token. This is where you will supply the required parameters for obtaining an
access_token using PKCE. Now, let's move on by following the steps below:
Authorization Code (With PKCE)as the Grant Type.
- Enter the
Redirect Urias the Callback URL.
- Enter the
Authorize Urlas the Auth URL.
- Enter the
Token Urlas the Access Token URL.
- Enter the
ClientIdas the Client ID.
- Finally, enter the scope.
Once all required values are set, then click the Get New Access Token button and it should prompt you to login with your Azure AD B2c username and password. When successful, it should generate an
access_token that you can use to access your secured API endpoints.
Note that the login prompt will only happen once since PKCE uses the
refresh_token to automatically acquire an new
access_token when your login session expires or when the token cached expires.
In my next article, I'll demonstrate how to integrate Authorization to secure your ASP.NET Core APIs that supports mutiple Authentication schemes such as user flows and client credentials flow. For the time being, just head over to this article to get started: Authorize with a specific scheme in ASP.NET Core
- Testing Web APIs with POSTMAN and Automating Bearer Token Generation
- IdentityServer4: Building a Simple Token Server and Protecting Your ASP.NET Core APIs with JWT
- Protected web API: App registration
- [Azure AD B2C: Authentication protocols](https://docs.microsoft.com/en-us/azure/active-directory-b2c/protocols-overview)
- How to secure a Web API built with ASP.NET Core using the Azure AD B2C
That's it! I hope you find this post helpful.