- Source: http://oauth2.thephpleague.com/authorization-server/implicit-grant/
- See also the flowchart at Which OAuth 2.0 grant should I use?"
- OAuth2 and Mojolicious
Implicit grant
The implicit grant is similar to the authorization code grant with two distinct differences.
It is intended to be used for user-agent-based clients (e.g. single page web apps [the web browser is the "user agent" [wikipedia]; your web app is the "client"]) that can’t keep a client secret because all of the application code and storage is easily accessible. [The user can view your web-application's source code from the browser itself.]
Secondly, instead of the authorization server returning an authorization code which is exchanged for an access token, the authorization server returns an access token.
[Recap: You want to access resources on e.g., Facebook, which reside on Facebook's Resource Server. To do this, your web application, running within a browser, redirects the user's browser to an Authorization Server. The Auth Server creates an access token which the Resource Server will accept. Somehow [[??]] this token gets passed back to your web application when the user's browser is somehow [[??]] redirected back to the web application.]
Flow
The client [the web page (YOUR-WEB-APP) running within the user's browser] will redirect the user [user's browser] to the authorization server [e.g., Facebook's auth server] with the following parameters in the query string:
response_type
with the valuetoken
client_id
with the client identifierredirect_uri
with the client redirect URI. This parameter is optional, but if not send the user will be redirected to a pre-registered redirect URI.scope
a space delimited list of scopesstate
with a CSRF token. This parameter is optional but highly recommended. You should store the value of the CSRF token in the user’s session to be validated when they return.
All of these parameters will be validated by the authorization server.
The user will then be asked to login to the authorization server and approve the client [the web-app in question. i.e., "Facebook [[Well, really, FB's authorization server]] wants to know whether you approve letting YOUR-WEB-APP access your Facebook account."].
If the user approves the client [your web-app] they [their browser] will be redirected back to the authorization server with the following parameters in the query string:
token_type
with the valueBearer
expires_in
with an integer representing the TTL of the access tokenaccess_token
a JWT signed with the authorization server’s private keystate
with the state parameter sent in the original request. You should compare this value with the value stored in the user’s session to ensure the authorization code obtained is in response to requests made by this client rather than another client application.
**Note** this grant does not return a refresh token.
[How or when does the user's browser reload the web-app? And how does the web-app get the token?]
[In the above, you may substitute YOUR-SYSTEM'S-AUTH-SERVER in place of "Facebook's auth server"]