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_id, 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:

OAuth 2.0: Implicit Flow is Dead, Try PKCE Instead | Postman Blog
Learn how to use PKCE for OAuth 2.0 in Postman, and why PKCE helps improve security for native, mobile, and browser-based apps.

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 access_token.

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: https://{domain}.b2clogin.com/{domain}.onmicrosoft.com/{SignUpSignInPolicyId}/oauth2/v2.0/authorize. The SignUpSignInPolicyId is 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: https://{domain}.b2clogin.com/{domain}.onmicrosoft.com/{SignUpSignInPolicyId}/oauth2/v2.0/token

You can obtain both endpoints from .well-known/openid-configuration endpoint. For example navigating to: https://{domain}.b2clogin.com/{domain}.onmicrosoft.com/{SignUpSignInPolicyId}/v2.0/.well-known/openid-configuration

  • 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 GUID value.
  • 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: https://{Domain}.onmicrosoft.com/{ApplicationName}/{ScopeName}
App Registrations - Set Redirect Uri
App Registrations - Supported Account Type

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:

Select 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:

  • Select Authorization Code (With PKCE) as the Grant Type.
  • Enter the Redirect Uri as the Callback URL.
  • Enter the Authorize Url as the Auth URL.
  • Enter the Token Url as the Access Token URL.
  • Enter the ClientId as 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

Useful Links

That's it! I hope you find this post helpful.