The token endpoint is used by the client to obtain an access token by presenting its authorization grant. Note that authentication requirements to this endpoint are configured by the application’s tokenEndpointAuthMethod property. For authorization_code and client_credentials grants, the application calls the POST /{environmentId}/as/token endpoint to acquire the access token.

For an authorization_code grant type in which the application’s tokenEndpointAuthMethod is set to CLIENT_SECRET_BASIC, the request looks like this. The <headerValue> represents a Base64-encoded representation of “username:password”, in which the username is the client_id and the password is the client_secret:

curl -X POST \
  'https://auth.pingone.com/{environmentId}/as/token' \
  -H 'Authorization: Basic <headerValue>' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=authorization_code&code={authCode}&redirect_uri=https://example.com'

For an authorization_code grant type in which the application’s tokenEndpointAuthMethod is set to CLIENT_SECRET_POST, the request looks like this:

curl -X POST \
  'https://auth.pingone.com/{environmentId}/as/token' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=authorization_code&code={authCode}&client_id={appID}&client_secret={appSecret}&redirect_uri=https://example.com'

For an authorization_code grant type in which the application’s tokenEndpointAuthMethod is set to NONE, the request looks like this:

curl -X POST \
  'https://auth.pingone.com/{environmentId}/as/token' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=authorization_code&code={authCode}&client_id={appID}&redirect_uri=https://example.com'

For a PKCE authorization request, the token request must include the code_verifier parameter:

curl -X POST \
  'https://auth.pingone.com/${environmentId}/as/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d `grant_type=authorization_code&code=${authCode}&redirect_uri=https://example.com&code_verifier=${codeVerifier}'

Supported parameters for the token request are:

Property Description
client_id A string that specifies the application’s UUID.
client_secret A string that specifies the the application’s client secret. This property is required only if the application’s tokenEndpointAuthMethod property is set to CLIENT_SECRET_POST.
code A string that specifies the authorization code returned by the authorization server. This property is required only if the grant_type is set to authorization_code.
code_verifier A large random string used in a PKCE authorize request. This string is used to create the code_challenge value passed to the authorization server in the request. The length an character set requirements for the code_verifier string is documented in Section 4.1 of RFC7636.
grant_type A string that specifies the grant type of the token request. Options are authorization_code, implicit, refresh_token, and client_credentials.
redirect_uri A string that specifies the URL used as the return entry point of the application. This is a required property only if the grant_type is set to authorization_code.

To obtain a refresh token along with an access token, the client must be configured with the refresh_token grant type and the authorization_code grant type. With this configuration, a refresh token is generated along with the access token. When obtaining the original access token, a refresh token is included in the response, which is tied to the client and the user session. As long as the session exists and it is not expired (30 days since the last sign on), the /{environmentId}/as/token endpoint can be used to exchange the refresh token for a new access token and refresh token. If the openid scope is granted, an ID token is also included.

When a new refresh token is issued, the previous refresh token is rotated to prevent token abuse, which is useful when client authentication is disabled. In addition, when a refresh token is exchanged, the activeAt property of the corresponding session is updated. This does not extend the duration of the session, but can be used to indicate that there is activity.

To revoke a refresh token, the corresponding session must be deleted. Session termination is supported only by the resource owner using the /{environmentId}/as/signoff endpoint or by disabling the user.

For more information about access token claims, see Access token claims.