Grant Types represent Identifier
for the OAuth 2.0 Protocol Flows
refer to the Types of Authorization Grants
within OAuth 2.0
and openID Connect
which represent various Use cases
within the Specifications
The Authorization Grant requires a grant_type parameters which represents the various Grant Types.
OAuth 2.0 focuses on client developer simplicity while providing specific Grant Types which have associated OAuth 2.0 Protocol Flows.
OAuth 2.0 is a very flexible standard and can be adapted to work in many different scenarios. The core specification describes four Grant Types:
The OAuth 2.0 specification details a fifth grant, the Refresh Token Grant, which can be used to "refresh" (i.e. get an "new" Access Token which has the same Authorization as the original.
There are other Grant Types that are NOT defined in The OAuth 2.0 Authorization Framework, that have gone through, or are currently in, the IETF ratification process:
Within OpenID Connect
node within the The openid-configuration
URI should show the Grant Types that a particular Authorization Server
The OpenID Connect spec provides a nice comparison of the three flows supported, reproduced here in a simplified form.
The flow used is determined by the response_type value contained in the Authorization Request. These response_type values select the following flows
Grant Types other than those defined in RFC 6749
are, so name collisions are avoided, to be URIs
as defined in section 4.5 on Extension Grants
Which Grant Types to Use? #
(or browser-based apps) run entirely in the browser
after loading the source code from a web page. Since the entire source code is available to the browser
, they cannot maintain the confidentiality of their client secret. The flow is exactly the same as the Authorization Code
, but at the last step, the Authorization Code
is exchanged for an access token without
sending the client Secret
Previously, it was recommended that browser-based apps use the Implicit Grant, which returns an access token immediately and does not have a token exchange step. In the time since the spec was originally written, the industry Best Practice has changed to recommend that the authorization code flow be used without the client secret. This provides more opportunities to create a secure flow, such as using the state parameter.
There might be more information for this subject on one of the following: