Grant Types

Overview#

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 SpecificationsThe 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:[2]

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:

OpenID Connect#

Within OpenID Connect the openid-configuration URI The grant_types_supported node within the The openid-configuration URI should show the Grant Types that a particular Authorization Server supports.

The OpenID Connect spec provides a nice comparison of the three flows supported, reproduced here in a simplified form.

Flow propertyCodeImplicitHybrid
All tokens returned from Authorization_endpoint✕✔✕
All tokens returned from Token_endpoint✔✕✕
Tokens NOT revealed to user-agent✔✕✕
Client can be authenticated✔✕✔
Refresh Token possible✔✕✔
Communication in one round trip✕✔✕
Most communication server-to-server✔✕varies

The flow used is determined by the response_type value contained in the Authorization Request. These response_type values select the following flows

response_type valueFlow
codeAuthorization Code Flow
id_tokenImplicit Flow
id_token token{Implicit Flow}
code id_tokenHybrid Flow
code tokenHybrid Flow
code id_token tokenHybrid Flow

Extension Grants#

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? [1][2][3]#

There are always many aspects regarding Security Considerations that are dependent on the specific implementation.
Application TypeOAuth ClientOAuth 2.0OpenID Connect
Web Application (with dedicated server-side component)ConfidentialAuthorization Code GrantAuthorization Code Flow
Desktop Native ApplicationConfidentialAuthorization Code GrantAuthorization Code Flow
Desktop Native ApplicationPublicAuthorization Code Grant with PKCEAuthorization Code Flow with PKCE
Native applicationPublicAuthorization Code Grant with PKCEAuthorization Code Flow with PKCE
SPA AppPublicAuthorization Code GrantAuthorization Code Flow See Notes OAuth Public Clients
JavaScript applicationeitherImplicit GrantImplicit Flow

Notes OAuth Public Clients#

Single-Page Applications (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.

More Information#

There might be more information for this subject on one of the following:

Please see our Copyright And Intellectual Property Page and Standard Disclaimer Pages!