OAuth 2 Grant Type Implicit §

The Implicit grant type is a simplified flow that can be used by public clients, where the access token is returned immediately without an extra authorization code exchange step.

The implicit grant type is used for mobile apps and web applications (i.e. applications that run in a web browser), where the client secret confidentiality is not guaranteed.

The implicit grant type is also a redirection-based flow but the access token is given to the user-agent to forward to the application, so it may be exposed to the user and other applications on the user’s device.

Also, this flow does not authenticate the identity of the application, and relies on the redirect URI (that was registered with the service) to serve this purpose.

The implicit grant type does not support refresh tokens.

Security concern §

OAuth 2 Grant Type Implicit Security

Workflow (basic) §

1. A user visits a website:

https://www.web-application.com

This website provides an online photo editing service: user can choose the photos stored in another website and edit.

https://www.photo-storage.com

The user wants to do that, so he click “allow access” button and is presented with an authorization link

This link looks just like the authorization code link, except it is requesting a token instead of a code (note the response type “token”).

https://www.authorization.com/v1/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=https://www.web-application.com/callback&scope=read

As you can see from above, the application requests a token directly because it is typically a JavaScript app running within a browser, therefore it is less trusted than a web app running on the server, hence cannot be trusted with the client_secret (which is required in the Authorization Code Grant).

2. User Authorizes Application When the user clicks the link, they must first log in to the service, to authenticate their identity (unless they are already logged in). Then they will be prompted by the service to authorize or deny the application access to their account.

3. User-agent Receives Access Token with Redirect URI If the user clicks “Authorize Application”, the service redirects the user-agent to the application redirect URI, and includes a URI fragment containing the access token. It would look something like this

https://www.web-application.com/callback#token=ACCESS_TOKEN

4. Application gets the token Now the application is authorized! It may use the token to access the user’s account via the service API, limited to the scope of access, until the token expires or is revoked.

Workflow (mobile) §

In case it is a mobile app, it is a bit more complicated, after step 3 above, the following steps would normally occur:

1. The user-agent follows the redirect URI but retains the access token.

2. The application returns a webpage that contains a script that can extract the access token from the full redirect URI that the user-agent has retained.

3. The user-agent executes the provided script and passes the extracted access token to the application.

Reference §

https://developer.okta.com/blog/2018/05/24/what-is-the-oauth2-implicit-grant-type https://iteritory.com/tutorial-on-oauth2-implicit-grant-flow/ https://medium.com/@justinsecurity/mobile-apps-and-oauths-implicit-flow-68e72c6515a1 Mobile Apps and OAuth’s Implicit Flow