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
Authorization Code Flow
Authorization Code Flow

Version management

Difference between version and

At line 1 added 119 lines
!!! Overview
[{$pagename}] is the [OAuth 2.0 Protocol Flow] for the [Authorization Code] [Grant Type] which would typically be used for [website] type applications.
[{$pagename}] is also called __3-legged OAuth__ and is a relatively high [Level Of Assurance].
!! [OAuth 2.0 Security Best Current Practice|https://tools.ietf.org/id/draft-ietf-oauth-security-topics-13.html#rfc.section.2|target='_blank']
states:\\
Clients utilizing the authorization grant type [MUST] use [PKCE] [RFC 7636] in order to (with the help of the [Authorization Server]) detect and prevent attempts to inject (replay) [Authorization Codes] into the [Authorization Response]. The [PKCE] challenges must be transaction-specific and securely bound to the [user agent|User-agent] in which the transaction was started and the respective client. [OpenID Connect] clients [MAY] use the [nonce] parameter of the [OpenID Connect] [Authentication Request] as specified in [OpenID] in conjunction with the corresponding ID Token claim for the same purpose.
%%information
Note: although [PKCE] so far was recommended as a mechanism to protect [native apps|Native application], this advice __applies to all kinds of OAuth clients__, including [web] [applications].
%%
Clients [SHOULD] use [PKCE] [Code_challenge_methods] that do not expose the [PKCE] [Code_verifier] in the [Authorization Request]. (Otherwise, the attacker A4 can trivially break the security provided by [PKCE].) Currently, [S256] is the only such method.
[AS|Authorization Server] [MUST] support [PKCE] [RFC 7636].
[AS|Authorization Server] [SHOULD] provide a way to detect their support for [PKCE]. To this end, they [SHOULD] either (a) publish, in their AS [metadata|OAuth 2.0 Authorization Server Metadata] ([RFC 8414]), the element [code_challenge_methods_supported] containing the supported [PKCE] [[Code_challenge_methods]] (which can be used by the client to detect [PKCE] support) or (b) provide a deployment-specific way to ensure or determine [PKCE] support by the [AS|Authorization Server].
[Authorization Servers] [SHOULD] furthermore consider the recommendations given in [RFC 6819], Section 4.4.1.1, on authorization code replay prevention.
!! The Flow
The [authorization Code Grant] type is used to obtain both [access_tokens] and [refresh_tokens] and is optimized for [OAuth Confidential Clients]. Since this is a [redirection|URL redirection]-based flow, the [OAuth Client] must be capable of interacting with the [Resource Owner]'s [user-agent] (typically a web [browser]) and capable of receiving incoming requests (via [URL redirection]) from the [Authorization Server].
{{{
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
Figure 3: Authorization Code Flow
}}}
Note: The lines illustrating steps (A), (B), and (C) are broken into two parts as they pass through the [user-agent].
!! Known in Advance
Some basic conditions must exist in advance:
* The [OAuth Client] [MUST] be aware of the correct [Authorization Server] associated with the [Resource Server]
* The [OAuth Client] [MUST] have registered with the correct [Authorization Server] and provided them with his:
** [Client_id]
** [Client Secret]
** [Redirect URI|Redirect_uri]
* The [OAuth Client] [MUST] know the [Authorization_endpoint].
* The specifications __do not__ indicate any communication between the [Authorization Server] associated with the [Resource Server].
Many [Authorization Servers] and most [OpenID Connect Providers] support [Openid-configuration] [Discovery Mechanism]
The flow illustrated in Figure 3 includes the following steps:
!! (A) [Authorization Request]
The [OAuth Client] initiates the flow by directing the [user-agent] to the [Authorization_endpoint] with an [Authorization Request] wihich includes:
* [client_id]
* [OAuth Scope]
* [state|OAuth state parameter]
* [Redirect_uri] which the [Authorization Server] will send the [user-agent] back once access is granted (or denied).
!! (B) [Authorization Grant]
The [Authorization Server] [authenticates|Authentication] the [Resource Owner] (via the [user-agent]) ([Authentication Method] is undefined in [OAuth 2.0]) and establishes whether the [Resource Owner] grants or denies the [OAuth Client]'s [Authorization Request].
!! (C) [Authorization Response]
Assuming the [Resource Owner] grants access, the [Authorization Server] redirects the [user-agent] back to the [OAuth Client] using the [redirect URI|Redirect_uri] provided in the [Authorization Request] earlier (or the during [OAuth 2.0 Client Registration]. The [URL redirection] [URI] includes an [Authorization Code] and any [local state|OAuth state parameter] provided by the [OAuth Client] earlier.
The [OAuth Client] [MUST] validate that the [OAuth state parameter] value returned in the [Authorization Response] is identical to the value sent in the [Authorization Request]
!! (D) [OAuth Token Request]
The [OAuth Client] requests an [Access Token] from the [Authorization Server]'s [token_endpoint] by including the [Authorization Code] received in the previous step. When making the request, the [OAuth Client] authenticates with the [Authorization Server]. The [OAuth Client] includes the [redirect URI|Redirect_uri] used to obtain the [Authorization Code] for verification.
!! (E) [OAuth Token Response]
The [Authorization Server]:
* [authenticates] the [OAuth Client]
* validates the [Authorization Code]
* ensures that the [redirect URI|Redirect_uri] received matches the [URI] used to redirect the [OAuth Client] in step (C).
If validation is successful, the [Authorization Server] responds back with:
* [Access Token]
* [Refresh Token] (Optional)
* and (IF) [OpenID Connect] [Id_token]
! [OAuth Client] [Validations]
* [Access Token Validation]
* [Identity Token Validation]
* [OAuth Scope Validation]
!! Access [Resources]
The [OAuth Client] can now use the [Access Token] to request resources from the [Resource Server]. The [Access Token] serves as both:
* [Authentication] of the [OAuth Client]
* [Authorization] by the [Resource Owner] (user) to to access the [Resource Server].
* [OpenID Connect] the [Access Token] can be used to access the [Userinfo_endpoint]:
** [UserInfo Request]
** [UserInfo Response]
!! [Best Practices OpenID Connect]
Please always follow the [Best Practices OpenID Connect]
!! 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
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop