Skip to main content
For Authlete 2.x documentation, see 2.x version.

​
Preface

As a general recommendation, prioritize using the authorization code flow (with PKCE). If the authorization code flow is not an option, carefully evaluate and consider alternative methods only after thoroughly understanding the characteristics and implications of each flow.

​
Grant Types in the Authlete Management Console

You can configure Grant Types in the Authlete Management Console. Authlete supports the following grant types:
  • AUTHORIZATION_CODE
  • IMPLICIT
  • PASSWORD
  • CLIENT_CREDENTIALS
  • REFRESH_TOKEN
  • CIBA
  • DEVICE_CODE
  • TOKEN_EXCHANGE
  • JWT_BEARER
  • PRE_AUTHORIZED_CODE

​
Service Settings

Authlete allows grant type configuration in service settings:
  1. Log in to the Authlete Management Console
  2. Click on your Organization name and choose your Service.
  3. Navigate to Service Settings > Endpoints > Global Settings
  4. Under the Supported Grant Types section, select desired grant types.
  5. Click Save Changes to update your service settings.
grant_type_1

​
Client Settings

Authlete allows grant type configuration in client settings:
  1. Log in to the Authlete Management Console
  2. Click on your Organization name and choose your Service.
  3. Navigate to Client Settings > Endpoints > Global Settings
  4. Under the Supported Grant Types section, select desired grant types.
  5. Click Save Changes to update your client settings.
cgrant_type_2

​
Grant Flow Details

The grant types defined in RFC6749 are as follows: There are five types. For each grant type, the elements issued from the authorization endpoint or token endpoint to the client application differ.
FlowAuthorization EndpointToken Endpoint
Authorization CodeAuthorization CodeAccess token, Refresh token
ImplicitAccess Token-
Resource Owner Passwords Credentials-Access token, Refresh token
Client Credentials-Access token
Refresh Token-Access token, Refresh token

​
Authorization Code Flow

This is the most popular grant flow. This flow begins by issuing a short-lived authorization code from the authorization endpoint. The authorization code is then exchanged for an access token at the token endpoint. This is the standard OAuth 2.0 flow. When a token is requested directly from a client (e.g., a public client) that cannot securely store confidential information like a client secret—such as a mobile app—it is essential to use PKCE (Proof Key for Code Exchange) in addition to the authorization code flow.

​
Implicit

This flow issues an access token directly from the authorization endpoint. Unlike the authorization code flow, no refresh token is issued. While this flow was originally designed for scenarios such as token requests from single-page applications (SPAs), the authorization code flow with PKCE is now the recommended approach for SPAs.

​
Resource Owner Passwords Credentials

This flow involves receiving the resource owner’s (end user’s) ID and password to issue an access token. However, it is generally avoided because the resource owner’s credentials are exposed to the client application. This flow is typically used only during transitional phases when implementing OAuth 2.0.

​
Client Credentials

This grant flow is defined for clients with no users involved. A client obtains an access token from an authorization server using its own credentials (e.g. a pair of client ID and client secret, a client certificate, a SAML assertion). This flow issues an access token based solely on client authentication. It is typically used when the client and the resource owner are the same entity.

​
Refresh Token

This is the flow to present the refresh token and have the access token reissued. The grant flow is defined to refresh previously issued access tokens (and refresh tokens). A client obtains an access token (and a new refresh token) from an authorization server using a refresh token previously obtained using other grant flows.