--- title: Grant types description: To obtain an access token, a client interacts with an OAuth authorization server (AS), sending a request for an access token that includes an access grant. An access grant is also used when a resource server (RS) requests validation of an access token from the AS. component: pingfederate version: 13.1 page_id: pingfederate:introduction_to_pingfederate:pf_grant_types canonical_url: https://docs.pingidentity.com/pingfederate/13.1/introduction_to_pingfederate/pf_grant_types.html llms_txt: https://docs.pingidentity.com/pingfederate/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md revdate: March 27, 2024 section_ids: primary-grant-types: Primary grant types extension-grant-types: Extension grant types --- # Grant types To obtain an access token, a client interacts with an OAuth *(tooltip: \
\

A standard framework that enables an application (OAuth client) to obtain access tokens from an OAuth authorization server for the purpose of retrieving protected resources on a resource server.\

\
)* authorization server (AS), sending a request for an access token that includes an access grant. An access grant is also used when a resource server (RS) requests validation of an access token from the AS. ## Primary grant types OAuth defines several different access grant types. Each grant type reflects different authorization mechanisms. * Authorization code `authorization_code`\ An authorization code is returned to the client through a browser redirect after the resource owner (RO) gives consent to the AS. The client subsequently exchanges the authorization code for an access token and often a refresh token. RO credentials are never exposed to the client. * Resource owner password credentials `password`\ The client collects the RO's password and exchanges it at the AS for an access token and often a refresh token. This grant type is suitable in cases where the RO has a trust relationship with the client, such as its computer operation system or a highly-privileged application because the client must discard the password after using it to obtain the access token. * Refresh token `refresh_token`\ A refresh token often returns with an access token. Once the original access token expires, the corresponding refresh token is sent to the AS to obtain a fresh access token and fresh refresh token without requiring the RO to re-authenticate. This allows short-lived access tokens to exist between the client and the resource server and long-lived tokens between the client and the AS.The refresh token grant type only works in conjunction with either the authorization code or RO password credentials grant type. | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | | When an attempt to replay an invalid refresh token is noticed, PingFederate revokes the entire chain of refresh and access tokens, forcing a re-authentication, subject to sessions and persistent grant settings. | * Implicit `implicit`\ A browser redirect responds to the RO authorization request, rather than an intermediate authorization code, and returns an access token to the client. This grant type works for clients incapable of keeping client credentials confidential for use in authenticating with the AS, such as client applications implemented in a browser using a scripting language like JavaScript. * Client credentials `client_credentials`\ The client presents its own credentials to the AS to obtain an access token. This access token is either associated with the client's own resources, and not a particular RO, or with a RO for whom the client is otherwise authorized to act. This is the grant type to use for machine-to-machine authentication, server-to-server authentication, and worker applications. ## Extension grant types OAuth provides an extension mechanism for defining new extension grant types to support additional clients or to provide a bridge between OAuth and other trust frameworks. An OAuth client uses an extension grant type by specifying an absolute URI as the value of the `grant_type` parameter and by adding any additional parameters necessary when contacting the token endpoint at `/as/token.oauth2`. PingFederate supports the following extension grant types: * Assertion grants * JWT Bearer `urn:ietf:params:oauth:grant-type:jwt-bearer`\ The client obtains a JSON web token (JWT) and uses it to request an access token from the AS. This grant type allows a client to use an existing trust relationship, expressed through a JWT, without a direct user approval step at the AS. PingFederate also supports using an Identity Assertion JWT (ID-JAG) as the JWT assertion in a JWT bearer grant request to obtain an access token. * SAML 2.0 Bearer `urn:ietf:params:oauth:grant-type:saml2-bearer`\ The client obtains a SAML 2.0 Bearer assertion and uses it to request an access token from the AS. Similar to the JWT Bearer grant type, this grant type allows a client to use an existing trust relationship, expressed through a SAML assertion, without a direct user approval step at the AS. | | | | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | The SAML assertion used for this grant type generally cannot be a browser-based SSO assertion. To ensure its validity, the assertion must be associated with WS-Trust security token service (STS) processing. | * Client-initiated backchannel authentication (CIBA) grant `urn:openid:params:grant-type:ciba`\ The client presents an identity hint to the AS. The AS identifies the RO based on the hint provided and then authenticates and obtains authorization from the RO through an out-of-band flow. Depending on the setup, the client either polls the AS for the authorization result or wait for a signal from the AS to return to the AS for the authorization result. If the RO approves the authentication request, the AS returns an access token to the client. Otherwise, the AS returns an error message per the specification. * Device authorization grant `urn:ietf:params:oauth:grant-type:device_code`\ The client presents a device code and user code to the AS to identify the device-authorization session and obtain an access token. This access token is associated with a RO for whom the client is otherwise authorized to act. * token exchange grant `urn:ietf:params:oauth:grant-type:token-exchange`\ The client presents a security token to the AS. In exchange, the AS returns another kind of security token to the client. The new token might be an access token that is more narrowly scoped for a downstream service or it could be an entirely different kind of token. This grant type supports subject and actor tokens employing impersonation and delegation. PingFederate also supports issuing an Identity Assertion JWT (ID-JAG) through token exchange when the `requested_token_type` is `urn:ietf:params:oauth:token-type:id-jag`. * Validation grant `urn:pingidentity.com:oauth2:grant_type:validate_bearer`\ This proprietary PingFederate OAuth extension enables an RS to act as a client in the request/response exchange with PingFederate as the AS in this scenario. The grant type allows an RS to check with PingFederate on the validity of a bearer access token received from a client making a protected-resources call.