OAuth 2.0 - Authorisation Code Grant WorkFlow

Authorisation Code WorkFlow

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

The workflow described in the above picture succinctly potrays the interaction between the four roles, ie. The User, Client App, Authorisation Server and Resource Server. 

Movement of web Requests, right when the User makes the first http request to access Client app, till the Client App is able to serve the desired resource to the User.Between these two ends lies various other steps of the Workflow, which are all described, in details, below.

Different Url End Points, residing on either Client Apps or the Authorisation Server, are also described below.

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 during Client App Registration ( see Client Registration ). The Authorisation server appends a Query paramter 'code' to the pre Registered Redirection Url of the Client. Client ( on redirection via the user-agent ) recives this 'code', which serves as an indicator to the Client that User had been successfully authenticated. This can be referred to as 'Authorisation Code'. If the User authentication fails, the redirect url then would contain different query parameters like 'error'' and 'error_description'. 
5. Client App to Authorisation Server - After successfully procuring the 'Authorisation code' , client exchanges this code for an 'Access Token'. For this the Client submits ( POST ) 'Authorisation Code' along with the 'Client Id' and 'Client Secret' ( these client_id and client_secret keys were received by the Client during Client Registration ). This submission of the authorisation code, client id and client secret is directed to an Url which can be referred to as 'Token End Point', which resides on the Authorisation Server. The Authorisation Server, upon validating the Client code, id and secret, responds with an 'Access Token'. This interation, again, necessarily involves TLS ( Transport layer security ).
6. 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. Access Token is confined within the scope of the Client app and is not exposed to the user-agent. Steps 7, 8, 9, 10, 11 portrayed in the above pictorial representation, demonstrates, different user requests to the Client App which are served by the Client app with the use of 'Acccess Token', wherein this 'access token' is exchaged between the Client App and the Resource Server with every http request.

 << previous      client registration     >> next