---
title: Grant types
description: OAuth 2 and OpenID Connect define the authorization grant types by which a client application obtains an authorization grant in the form of an access token. PingOne supports the following grant types:
component: pingone-api
page_id: pingone-api:foundations:authentication-concepts/access-tokens-and-id-tokens/grant-types
canonical_url: https://developer.pingidentity.com/pingone-api/foundations/authentication-concepts/access-tokens-and-id-tokens/grant-types.html
section_ids:
  authorization-code: Authorization code
  implicit: Implicit
  client-credentials: Client credentials
  refresh-token: Refresh token
  device-code: Device code
  token-exchange: Token exchange
  client-initiated-backchannel-authentication-ciba: Client-Initiated Backchannel Authentication (CIBA)
---

# Grant types

OAuth 2 and OpenID Connect define the authorization grant types by which a client application obtains an authorization grant in the form of an access token. PingOne supports the following grant types:

## Authorization code

This grant type is used by web applications. The authorization request generates an authorization code that is exchanged for an access token. For more information, refer to [Authorization request with a code grant](../../../auth/openid-connect-oauth-2/authorize-authorization_code.html#get-authorize-authorization_code-get) in *Platform Auth APIs*.

## Implicit

This grant type is intended for use by native applications or client-side web applications with no server-side component. The implicit grant type is for applications that cannot guarantee the confidentiality of the client secret.

In this flow, the client makes a request to the server's authorization endpoint. If the request contains the `id_token` response type and the `openid` scope, then it is considered an authentication (OpenID Connect) request, and an ID token is issued. For more information, refer to [Native and single-page applications](../authorization-and-authentication-by-application-type/native-and-single-page-applications.html).

## Client credentials

This grant type is made directly to the token endpoint and is used to request an access token for either:

* Resources owned by the client rather than any specific end user.

* Resources belonging to multiple end users.

The client uses HTTP basic authentication with its `client ID` and `client secret` to authenticate itself to the token endpoint and must specify a `Content-Type` of `application/x-www-form-urlencoded`. For more information, refer to [Obtain an access token](../../../auth/openid-connect-oauth-2/token-admin-app-client_credentials.html#post-token-admin-app-client_credentials) in *Platform Auth APIs*.

## Refresh token

This grant type is used by applications to exchange the refresh token for a new access token. It gives applications the ability to acquire a valid access token without additional interaction. For more information, refer to [Obtain an access token](../../../auth/openid-connect-oauth-2/token-refresh_token-client-secret-basic.html#post-token-refresh_token-client_secret_basic) in *Platform Auth APIs*.

## Device code

This grant type is used by applications to return an activation code in the response to the `POST /{{envID}}/as/device_authorization` request. It gives OAuth enabled devices such as smart TVs the ability to complete user authorization and access protected resources. For more information, refer to [Device Authorization Grant](../../../auth/openid-connect-oauth-2/device-authorization-grant.html) in *Platform Auth APIs*.

## Token exchange

This grant type requires applications to provide a subject token and optionally an actor token and returns an access token for a custom resource. For more information, see [Token](../../../auth/openid-connect-oauth-2/token-intro.html).

## Client-Initiated Backchannel Authentication (CIBA)

This grant type is used to generate an out-of-band authentication request that is sent to the user on a separate device, such as a mobile phone. The user approves or denies the authentication request on the separate device, and the client application polls the token endpoint until it receives a success response or an error response indicating a terminal state. For more information, refer to [CIBA grant type](../authorization-flow-by-grant-type/ciba-grant-type.html).