Azure AD B2C: Requesting access tokens
An access token (denoted as access_token in the responses from Azure AD B2C) is a form of security token that a client can use to access resources that are secured by an authorization server, such as a web API. Access tokens are represented as JWTs and contain information about the intended resource server and the granted permissions to the server. When calling the resource server, the access token must be present in the HTTP request.
This article discusses how to configure a client application and web API in order to obtain an access_token.
Web API chains (On-Behalf-Of) is not supported by Azure AD B2C.
Many architectures include a web API that needs to call another downstream web API, both secured by Azure AD B2C. This scenario is common in native clients that have a web API back end, which in turn calls a Microsoft online service such as the Azure AD Graph API.
This chained web API scenario can be supported by using the OAuth 2.0 JWT Bearer Credential grant, otherwise known as the On-Behalf-Of flow. However, the On-Behalf-Of flow is not currently implemented in Azure AD B2C.
Register a web API and publish permissions
Before requesting an access token, you first need to register a web API and publish permissions (scopes) that can be granted to the client application.
Register a web API
- On the Azure AD B2C features menu on the Azure portal, click Applications.
- Click +Add at the top of the menu.
- Enter a Name for the application that will describe your application to consumers. For example, you could enter "Contoso API".
- Toggle the Include web app / web API switch to Yes.
- Enter an arbitrary value for the Reply URLs. For example, enter
https://localhost:44316/. The value does not matter since an API should not be receiving the token directly from Azure AD B2C.
- Enter an App ID URI. This is the identifier used for your web API. For example, enter 'notes' in the box. The App ID URI would then be
- Click Create to register your application.
- Click the application that you just created and copy down the globally unique Application Client ID that you'll use later in your code.
Scopes, which are analogous to permissions, are necessary when your app is calling an API. Some examples of scopes are "read" or "write". Suppose you want your web or native app to "read" from an API. Your app would call Azure AD B2C and request an access token that gives access to the scope "read". In order for Azure AD B2C to emit such an access token, the app needs to be granted permission to "read" from the specific API. To do this, your API first needs to publish the "read" scope.
- Within the Azure AD B2C Applications menu, open the web API application ("Contoso API").
- Click on Published scopes. This is where you define the permissions (scopes) that can be granted to other applications.
- Add Scope Values as necessary (for example, "read"). By default, the "user_impersonation" scope will be defined. You can ignore this if you wish. Enter a description of the scope in the Scope Name column.
- Click Save.
The Scope Name is the description of the Scope Value. When using the scope, make sure to use the Scope Value.
Grant a native or web app permissions to a web API
Once an API is configured to publish scopes, the client application needs to be granted those scopes via the Azure portal.
- Navigate to the Applications menu in the Azure AD B2C features menu.
- Register a client application (web app or native client) if you don’t have one already. If you are following this guide as your starting point, you'll need to register a client application.
- Click on API access.
- Click on Add.
- Select your web API and the scopes (permissions) you would like to grant.
- Click OK.
Azure AD B2C does not ask your client application users for their consent. Instead, all consent is provided by the admin, based on the permissions configured between the applications described above. If a permission grant for an application is revoked, all users who were previously able to acquire that permission will no longer be able to do so.
Requesting a token
When requesting an access token, the client application needs to specify the desired permissions in the scope parameter of the request. For example, to specify the Scope Value “read” for the API that has the App ID URI of
https://contoso.onmicrosoft.com/notes, the scope would be
https://contoso.onmicrosoft.com/notes/read. Below is an example of an authorization code request to the
Currently, custom domains are not supported along with access tokens. You must use your tenantName.onmicrosoft.com domain in the request URL.
In the following example, you replace these values:
<tenant-name>- The name of your Azure AD B2C tenant.
<policy-name>- The name of your custom policy or user flow.
<application-ID>- The application identifier of the client application that you registered.
<redirect-uri>- The Redirect URI that you entered when you registered the client application.
To acquire multiple permissions in the same request, you can add multiple entries in the single scope parameter, separated by spaces. For example:
scope=https://contoso.onmicrosoft.com/notes/read openid offline_access
You may request more scopes (permissions) for a resource than what is granted for your client application. When this is the case, the call will succeed if at least one permission is granted. The resulting access_token will have its “scp” claim populated with only the permissions that were successfully granted.
We do not support requesting permissions against two different web resources in the same request. This kind of request will fail.
The OpenID Connect standard specifies several special “scope” values. The following special scopes represent the permission to “access the user’s profile”:
- openid: This requests an ID token
- offline_access: This requests a refresh token (using Auth Code flows).
response_type parameter in a
/authorize request includes
scope parameter must include at least one resource scope (other than
offline_access) that will be granted. Otherwise, the
/authorize request will terminate with a failure.
The returned token
In a successfully minted access_token (from either the
/token endpoint), the following claims will be present:
||The application ID of the single resource that the token grants access to.|
||The permissions granted to the resource. Multiple granted permissions will be separated by space.|
||The application ID of the client application that initiated the request.|
When your API receives the access_token, it must validate the token to prove that the token is authentic and has the correct claims.
We'd love to hear your thoughts. Choose the type you'd like to provide:
Our feedback system is built on GitHub Issues. Read more on our blog.