!!! Overview
[{$pagename}] 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 [{$pagename}] 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 [{$pagename}]:[2]
* [Abstract Protocol Flow] - Is [ABSTRACT]
* [Authorization Code Grant] - [Authorization Code Grant] MUST use [PKCE]
* [Implicit Grant] - __[Deprecated]__ use [AppAuth] for [Mobile Device] [apps] or [Authorization Code Grant]
* [Resource Owner Password Credentials Grant]-  __[Deprecated]__ use [Authorization Code 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 [{$pagename}] 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 Authorization Grant] - Created to enable [OAuth 2.0] to be used on devices with no [WEB] [browser] such as game consoles and TVs. 
* [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 [{$pagename}] that a particular [Authorization Server] supports.

The [OpenID Connect spec provides a nice comparison|http://openid.net/specs/openid-connect-core-1_0.html#Authentication|target='_blank'] of the __three__ [flows|Grant Types] supported, reproduced here in a simplified form.
%%zebra-table
%%sortable
%%table-filter
||Flow property||[Code|Authorization Code Flow]||[Implicit|Implicit Flow]||[Hybrid|Hybrid Flow]
|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
%%zebra-table
%%sortable
%%table-filter
||[response_type] value||Flow
|[code|Authorization Code]|[Authorization Code Flow]
|[id_token]|Implicit Flow
|[id_token] [token]|{Implicit Flow}
|[code|Authorization Code] [id_token]|[Hybrid Flow]
|[code|Authorization Code] [token]|[Hybrid Flow]
|[code|Authorization Code] [id_token] [token]|[Hybrid Flow]

!! Extension Grants
[{$pagename}] 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|RFC 6749]. 

!! Which [{$pagename}] to Use? [1][2][3]
%%warning
There are always many aspects regarding [Security Considerations] that are dependent on the specific [implementation].
%%
||Application Type||[OAuth Client]||[OAuth 2.0]||[OpenID Connect]
|Web Application (with dedicated server-side component)|[Confidential|OAuth 2.0 Client Types#OAuthConfidentialClient]|[Authorization Code Grant]|[Authorization Code Flow]
|Desktop Native Application|[Confidential|OAuth 2.0 Client Types#OAuthConfidentialClient]|[Authorization Code Grant]|[Authorization Code Flow]
|Desktop Native Application|[Public|[OAuth Public Client]|[Authorization Code Grant] with [PKCE]|[Authorization Code Flow] with [PKCE]
|[Native application]|[Public|[OAuth Public Client]|[Authorization Code Grant] with [PKCE]|[Authorization Code Flow] with [PKCE]
|[SPA] App|[Public|[OAuth Public Client]||[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:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [RFC 6749|https://tools.ietf.org/html/rfc6749|target='_blank'] - based on data observed:2015-05-18
* [#2] - [A guide to OAuth 2.0 grants|http://alexbilbie.com/2013/02/a-guide-to-oauth-2-grants/|target='_blank'] - based on data observed:2015-05-18
* [#3] - [When To Use Which (OAuth2) Grants and (OIDC) Flows|https://medium.com/@robert.broeckelmann/when-to-use-which-oauth2-grants-and-oidc-flows-ec6a5c00d864|target='_blank'] - based on information obtained 2017-05-25