Table of Contents
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.
You can configure Grant Types in the Authlete Management Console.
Authlete supports the following grant types:
AUTHORIZATION_CODE IMPLICITPASSWORDCLIENT_CREDENTIALSREFRESH_TOKENCIBADEVICE_CODETOKEN_EXCHANGEJWT_BEARERPRE_AUTHORIZED_CODEAuthlete allows grant type configuration in service settings:
Authlete allows grant type configuration in client settings:
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.
| Flow | Authorization Endpoint | Token Endpoint |
|---|---|---|
| Authorization Code Authorization Code | Access token Refresh token | |
| Implicit | Access Token | - |
| Resource Owner Passwords Credentials | - | Access token Refresh token |
| Client Credentials | - | Access token Refresh token |
| Refresh Token | - | Access Token |
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.
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.
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.
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 assetion).
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.
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.