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
Implicit Grant
Implicit Grant

Version management

Difference between version and

At line 1 added 124 lines
!!! Overview
The [{$pagename}] ([IG]) is a [Deprecated] simplified [Authorization Request] and is optimized for clients implemented in a [browser] using a scripting language such as [JavaScript].
%%error
[{$pagename}] ([Implicit Flow]) is [Deprecated]
%%
Use the [Authorization Code Grant] with [PKCE]
November of [2018|Year 2018], new guidance was released that effectively deprecated this flow. Additional specs that speak to updated [OAuth 2.0 Security Best Current Practice] in general and [security for web apps|https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps|target='_blank'].
The OAuth 2.0 specification included the [{$pagename}] at a time when [browser] support for [SPAs] was much more limited. In particular, [JavaScript] did not have access to [browser] history or [LocalStorage]. Also, most providers did not allow [Cross-domain] [HTTP POST] requests to a [Token_endpoint], which is a requirement of the [Authorization Code Grant].
!! [Security Considerations]
Notice that after the [End-User] authenticates (C) below, the [Authorization Server] responds directly with [Access_token]. This means that the tokens are in the [browser]’s address bar as a result of the [Redirection]. That’s problematic since [Authorization Server] can't definitively know that your [browser] (the intended recipient) actually received the response.
This exposure of [access_token] is also problematic because modern [browsers] can do [browser] history syncing and they support [browser] extensions that could be actively scanning for [tokens] in the [browser] address bar. Leaking [tokens] is a security [Vulnerability].
The [Security Considerations] comes when you realize that unlike with a remote [server] [URL], there is no reliable way to ensure that the binding between a given [redirect_uri] and a specific [Device] [application] is honored. Any [application] on the [Mobile Device] can become a [Man-In-The-Middle] [attacker] in the [redirection] process and cause it to serve the [redirect_uri].
Unlike when using the [Authorization Code Grant] the you can only use the [Authorization Code] if you have access to the client’s [credentials] this is what saves web applications from impersonating each other: the [Client Secret] is stored on the [Website] and __NOT__ on the [browser].
!! [{$pagename}] Details
%%warning
[{$pagename}] is only suitable for [OAuth Client] applications that are [browser] based or [JavaScript] __NOT__ [Mobile Devices] or other [Applications] that could use a [Authorization Code Grant]
%%
In the [{$pagename}], instead of issuing the client an [Authorization Code], the [OAuth Client] is issued an [Access Token] directly as the result of the [Resource Owner] [authorization].
The [grant_type] is implicit, as no intermediate [credentials] such as an [Authorization Code] are issued and later used to obtain an [Access Token].
When issuing an [Access Token] during the [{$pagename}], the [Authorization Server] does not [authenticate] the [OAuth Client]. Although in some cases, the [OAuth Client] identity can be verified via the [redirect_uri] used to deliver the [Access Token] to the [OAuth Client]. The [Access Token] may be exposed to the [Resource Owner] or other [applications] with access to the [Resource Owner]'s [user-agent].
[{$pagename}]s improve the responsiveness and efficiency of some clients (such as a client implemented as an in-[browser] application), since it reduces the number of round trips required to obtain an [Access Token]. However, this convenience should be weighed against the [security] implications of using [{$pagename}]s, such as those described in [OAuth 2.0] Sections 10.3 and 10.16, especially when the [Authorization Code] [Grant Type] is available.
%%warning
There are NO [Refresh Tokens] with an [{$pagename}]
%%
[{$pagename}] is the [Grant Type] for the [Implicit Grant] which would typically be used with a [OAuth Public Client] as is often encountered in Mobile Apps where the [OAuth Client] can __NOT__ be trusted with [Credentials].
Since this is a [redirection]-based [Grant Type], 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 [redirection]) from the [Authorization Server].
%%warning
the [Access Token] may be exposed to the [Resource Owner] and other applications residing on the same device
%%
The [{$pagename}] type does not include [OAuth Client] authentication, and relies on the presence of the [Resource Owner] and the registration of the redirection URI. Because the [Access Token] is encoded into the redirection URI, the [Access Token] may be exposed to the [Resource Owner] and other applications residing on the same device.
%%prettify
{{{
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI --->| |
| User- | | Authorization |
| Agent -|----(B)-- User authenticates -->| Server |
| | | |
| |<---(C)--- Redirection URI ----<| |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| |----(D)--- Redirection URI ---->| Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) |<---(E)------- Script ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |
+---------+
}}} /%
The [{$pagename}] is illustrated includes the following steps:
!! (A)
The [client|OAuth Client] initiates the flow by directing the resource owner's [User-agent] to the [Authorization_endpoint]. The [client|OAuth Client] includes:
* [Client_id]
* requested [OAuth Scopes]
* local [state|OAuth state parameter]
* [redirect_uri] - to which the authorization server will send the [User-agent] back once access is granted (or denied).
!! (B)
The [Authorization Server] authenticates the [Resource Owner] (via the [User-agent]) and establishes whether the [Resource Owner] grants or denies the [client|OAuth Client]'s access request.
!! (C)
Assuming the [Resource Owner] grants access, the [Authorization Server] redirects the [User-agent] back to the [client|OAuth Client] using the [Redirect URI|Redirect_uri] provided earlier. The [Authorization Response] includes:
* [Access Token] in the URI fragment
!! (D)
The [User-agent] follows the redirection instructions by making a request to the [OAuth Client] (which does not include the fragment per [RFC 2616]). The [User-agent] retains the fragment information locally.
!! (E)
The web-hosted [OAuth Client] resource returns a web page (typically an HTML document with an embedded script) capable of accessing the full [Redirect URI|Redirect_uri] including the fragment retained by the [User-agent], and extracting the [Access Token] (and other parameters) contained in the fragment.
!! (F)
The [User-agent] executes the script provided by the web-hosted client resource locally, which extracts the [Access Token].
!! (G)
The [User-agent] passes the [Access Token] to the [OAuth Client].
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
* [#2] - [Implement the OAuth 2.0 Authorization Code with PKCE Flow|https://developer.okta.com/blog/2019/08/22/okta-authjs-pkce|target='_blank'] - based on information obtained 2019-08-23
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop