Overview#
Grant Types refer to the Types of Authorization Grants within OAuth 2.0.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:[2]
- Abstract Protocol Flow
- Authorization Code Grant - Typically for apps running on a web server
- Implicit Grant - typically for browser-based or mobile apps
- Resource Owner Password Credentials Grant
- Client Credentials Grant - typically for application access
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:
- OAuth 2.0 Message Authentication Code (MAC) Tokens
- OAuth 2.0 Device Profile - Created to enable OAuth 2.0 to be used on devices with no WEB browser such as game consoles.
- Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants - Enables exchange of SAML V2.0 Assertion for an Access Token (Not in the Core SPec)
- JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
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 property | Code | Implicit | Hybrid |
|---|---|---|---|
| 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 value | Flow |
|---|---|
| code | Authorization Code Flow |
| id_token | Implicit Flow |
| id_token token | {Implicit Flow} |
| code id_token | Hybrid Flow |
| code token | Hybrid Flow |
| code id_token token | Hybrid 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]#
| Application Type | OAuth Client | OAuth 2.0 | OpenID Connect |
|---|---|---|---|
| Web Application (with dedicated server-side component) | Confidential | Authorization Code Grant | Authorization Code Flow |
| Desktop Native Application | Confidential | Authorization Code Grant | Authorization Code Flow |
| Desktop Native Application | Public | Authorization Code Grant with PKCE | Authorization Code Flow with PKCE |
| Native application | Public | Authorization Code Grant with PKCE | Authorization Code Flow with PKCE |
| SPA App | Public | Authorization Code Grant | Authorization Code Flow See Notes OAuth Public Clients |
| JavaScript application | either | Implicit Grant | Implicit 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:- Abstract Protocol Flow
- Access Token Request
- Access Token Validation
- Application_type
- Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
- Authorization API
- Authorization Code
- Authorization Code Flow
- Authorization Code Grant
- Authorization Request
- Authorization Request Parameters
- Federated Authorization for UMA 2.0
- Grant Types
- Grant_type
- Grant_types_supported
- Implicit Flow
- Implicit Grant
- JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
- OAuth 2.0
- OAuth 2.0 Audience Information
- OAuth 2.0 Protocol Flows
- OAuth 2.0 Token Exchange
- OAuth 2.0 Token Exchange Request
- OAuth 2.0 Tokens
- OAuth 2.0 Vulnerabilities
- OAuth Dynamic Client Registration Metadata
- OpenID Connect
- OpenID Connect Flows
- Openid-configuration
- Protection API
- Reciprocal OAuth
- Refresh Token Grant
- Requested_token_use
- Resource Owner Password Credentials Grant
- Resource Parameter
- Response_type
- Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants
- UMA 2.0 Grant for OAuth 2.0
- UMA 2.0 Grant for OAuth 2.0 Authorization
- Unauthorized_client
- Web Blog_blogentry_140615_1
- [#1] - RFC 6749 - based on data observed:2015-05-18
- [#2] - A guide to OAuth 2.0 grants - based on data observed:2015-05-18
- [#3] - When To Use Which (OAuth2) Grants and (OIDC) Flows - based on information obtained 2017-05-25
