Configure Microsoft Azure AD to mint access tokens that can be validated locally when PingAccess is protecting an API application.
Make sure that you've configured an application in Microsoft Azure AD. If you haven't, see creating Azure AD Graph API applications.
If you're using PingAccess to
protect an API application and want to use Azure AD as the common token provider,
you must complete this task. Because Microsoft Azure AD doesn't have an
introspection endpoint to validate access tokens remotely, you
must use a key from the JSON Web Key Set (JWKS) endpoint to validate access tokens
locally. This task prevents Azure AD from adding a nonce value to the access token
after it's been signed because adding the nonce value blocks PingAccess's ability to validate
the access token.
However, if you're protecting a web application with PingAccess and want to configure
Azure AD as the common token provider, see configuring token provider-specific options instead. You don't need to
complete this task when PingAccess is protecting a web application because the
userinfo endpoint in Azure AD can use the nonce value that
Azure AD inserts into the access token and validate the access token remotely.
To configure Azure AD to mint an access token that can be validated locally:
In your Azure AD environment, create a scope for the API application that you
want to protect:
- On the Overview page of your Azure AD application, go to the Essentials section and copy the Application (client) ID.
Go to Scopes section, click
Add a scope.
and in the
Use the following format to create the scope for your API application:
api://<Application (client) ID>/<scope name>
Make sure to paste in the Application (client) ID that you copied in step 1a.Important:
This scope is what prevents Azure AD from minting an access token with a nonce value that's only usable by the
In the PingAccess
administrative console, set up Azure AD as a common token provider:
- Go to Common Token Provider . and select
- Fill out the OpenID Connect tab according to the configuring PingAccess to use Azure AD as the token provider and configuring token provider-specific options procedures.
- Fill out the OAuth Authorization tab according to the configuring OAuth authorization servers procedure.
If you've configured a remote token access validator on your PingAccess application and try to remove the Introspection Endpoint or save without configuring it on the OAuth Authorization Server tab, you get the following error message:
Introspection endpoint is required as there are applications that use remote token validation.
Remove the remote access token validator before filling out your configuration on the OAuth Authorization Server tab.
In your PingAccess application, set up a JWKS endpoint
validator to perform local validation in Azure AD:
- Go to Expand icon to view more details about the API application that you want to protect, then click the Pencil icon. , click the
In the Application Type section, click
+ Create below the Access
Do not select the remote access token validator, Token Provider, in the Access Validation list. You must instead set up a local access token validator.Note:
If you try to use a remote access token validator on your PingAccess API application without first configuring the introspection endpoint on the OAuth Authorization Server tab of the Token Provider page, you get the following error message:
Cannot use remote validation as authorization server does not have an Introspection endpoint.
- In the Name field, enter a name for the token validator.
- In the Type list, select JSON Web Key Set (JWKS) Endpoint.
In your Azure AD application, go to the
Endpoints tab on the
Overview page and copy the full URL of the
OIDC metadata documentendpoint.
OpenID Connect (OIDC)metadata document URL in a new tab and copy the value of the OpenID Connect (OIDC) OIDC An authentication protocol built on top of OAuth that authenticates users and enables clients (relying parties) of all types to request and receive information about authenticated sessions and users. OIDC is extensible, allowing clients to use optional features such as encryption of identity data, discovery of OpenID Providers (OAuth authorization servers), and session management.
jwks_uriproperty beginning after the https://login.microsoft.online.com segment.
<Directory (tenant) ID>/discovery/v2.0/keys
In PingAccess, return to the New
Access Token Validator page and paste the
jwks_urivalue that you copied into the Path field.
- Click Save.
Add the scope that you set up in Azure AD to your PingAccess
- In your Azure AD application, go to Scopes section, copy the full path of the scope that you set up in step 1b. and in the
- In PingAccess, go to , click the Expand icon to view more details about the web session associated with your API application, then click the Pencil icon.
- Click Show Advanced Settings, then in the Scopes field, paste the full path of the scope that you copied in step 4a.
- Click Save.
You now have an access token that PingAccess can validate and have finished configuring your PingAccess application, web session, and access token validator to use Azure AD as the common token provider.