Overview#
Implicit Flow is the OAuth 2.0 Protocol Flow 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 flow, the 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.
Unlike the Authorization Code Grant type, in which the client makes separate requests for authorization and for an Access Token, the client receives the Access Token as the result of the authorization request.
The Best Practice Around Implicit Flow in OAuth 2.0 is Changing#
Implicit Flow in OAuth 2.0 was created nearly 10 years ago, when browsers worked very differently than they do today. The primary reason the Implicit Flow was created was because of an old limitation in browsers where it used to be the case that JavaScript could only make requests to the same server that the page was loaded from. However, the standard OAuth Authorization Code flow requires that a HTTP POST request is made to the OAuth Authorization Server's Token_endpoint, which is often on a different DNS Domain than the app. That meant there was previously no way to use this flow from JavaScript. The Implicit Flow worked around this limitation by avoiding that HTTP POST request, and instead returning the access_token immediately in the Redirection.Today, Cross Origin Resource Sharing (CORS) is universally adopted by browsers, removing the need for this compromise. CORS provides a way for JavaScript to make requests to servers on a different domain as long as the destination allows it. This opens up the possibility of using the Authorization Code Grant in JavaScript.
Implicit Flow has always been seen as a compromise compared to the Authorization Code flow. For example, the spec provides no mechanism to return a Refresh_token in the Implicit Flow, as it was seen as too insecure to allow that. The spec also recommends short lifetimes and limited scope for access tokens issued via the Implicit Flow.
The implicit grant type does not include 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.
+----------+
| 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 |
| |
+---------+
(A) #
The client initiates the flow by directing the resource owner's User-agent to the Authorization_endpoint. The client includes:- Client_id
- requested OAuth Scopes
- local state
- 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's access request.(C)#
Assuming the Resource Owner grants access, the Authorization Server redirects the User-agent back to the client using the 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 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:- [#1] - Is the OAuth 2.0 Implicit Flow Dead?
- based on information obtained 2019-05-03
