!!! 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