OAuth 2.0 - Implicit Grant WorkFlow

Implicit WorkFlow

A pictorial representation of the OAuth 2.0 WorkFlow to obtain Authorisation Grant through the Implicit mechanism

The workflow described in the above picture succinctly portrays the interaction between the four roles, i,e the User, the Client App, the Resource Server and the Authorisation Server. This flow is similar to the 'Authorisation Code WorkFlow'
In this Type of workflow, the Client App runs within the User's user-agent, i.e within the Browser itself. See also Different Types of Authorisation Grants

1. User to Clien App - End User via User-agent, like Browser makes a request to access Client App.
2. Client App to User - Client App sends back a Authentication Url to the user. This Authentication Url which can also be referred to as 'Authorisation End Point' , is a Url to the Authorisation server, which resides on the OAuth Server and is used to Authenticate the Credential of User i.e User login and Password on the Resource Server. Client Apps maintain these End Points, pre downloaded, perhaps through Resource Server's OAuth Documentation page.
3. User to Authorisation Server - User , via the user-agent, accesses the 'Authorisation End Point' given to it by the Client App. This Request goes to the Authorisation Server, which then serves a Login page to the User, and asks User to enter its Login Username and Password. These are User's private credentials, which the User uses to access its resources on the Resource Server. At this point, to ensure complete security, User must verify that the login page is indeed served by its Resource Server, and not by some malicious website which can steal away its Credentials. This interaction necessarily involves TLS( Transport layer security ). Needless to say, that authentication of user credentials also involves a interaction between Authorisation Server and Resource Server. This interaction between the two serves is out of the scope of the OAuth 2.0 Specifications.
4. Authorisation Server to user-agent to Client App - Authorisation server, on successful validation of User Credentials, redirects user-agent to a Redirect Url on the Client App. This Redirect Url can be referred to as 'Redirection End Point' and it resides on the Client App. This Redirect Url is an already Registered Url on Client App Registration ( see Client Registration ). The Authorisation server appends a Query parameter 'access_token' to the pre Registered Redirection Url of the Client. The Client ( on redirection via the user-agent ) receives this 'access_token', which is all that the Client App requires to access the Resources on the Resource Server. Thus, this flow allows the Client to bypass the extra step of Client Authorisation via the Authorisation code. Hence it involves fewer number of requests to access a proctected resource. If the User authentication fails, the redirect url then would contain different query parameters like 'error'' and 'error_description'.
5. Client to Resource Server - Client now uses 'Access Token' to access Resources ( requested by the User ) on the Resource server. This 'Access Token' serves as an indicator to both, a valid User Authentication as well as a Authorised Access of resources by the Client. As the Client runs within the User's Browser, hence, the Access Token is not confined within the scope of the Client app and is exposed to the user-agent. 
6. Steps 6, 7 of the above pictorial representation, demonstrates the different user requests to the client app, which are served by the Client App with the use of Access Token, wherein, this Access Token is exchanged between the Client App and Resource Server with every http request

   >> next      client registration         << previous