This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Grant Types
Grant Types

Version management

Difference between version and

At line 1 added 80 lines
!!! 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
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop