This a is very commonly used grant type and works on redirection at the server. It is highly suitable for server-side applications where the source code is hosted on the server and nothing is available on the client. The following diagram explains the authorization code grant type flow:

The steps in the preceding diagram are explained in detail here:

1. The resource owner of the secured resource is presented with a screen in the browser to authorize the request. Here is a sample authorization link: https://<DOMAIN>/oauth/authorize?response_type=code&client_id=<CLIENT_ID>&redirect_uri=<CALLBACK_URL>&scope=<SCOPE>.

These are the important query parameters in the previous link:

• • client_id: The client application ID that we got while registering the application with the service provider
  • redirect_uri: After successful authorization, the server redirects to this URL supplied
  • response_type: A very important parameter the client uses to ask the server for the authorization code
  • scope: Specifies the level of access that it requires

2. If the resource owner (user) allows this, they click on the authorize link, which is sent to the authorization server.
3. If the authorization request sent to the authorization server is validated and found to be successful, the client receives the authorization code grant from the authorization server appended as a query parameter in the callback URL (<CALLBACK_URL>?code=<AUTHORIZATION_CODE>) specified in Step 1.
4. Using the authorization grant, the client application requests an Access Token from the authorization server (https://<DOMAIN>/oauth/token?client_id=<CLIENT_ID>&client_secret=<CLIENT_SECRET>&grant_type=authorization_code&code=<AUTHORIZATION_CODE>&redirect_uri=CALLBACK_URL).

In this URL, the client application's client_secret also has to be passed, along with the grant_type parameter, which states that the code passed is the authorization code.

5. The authorization server validates the credentials and authorization grant and sends the Access Token to the client application, preferably in the form of JSON.
6. The client application calls the protected resource on the resource server using the Access Token received in Step 5.
7. If the Access Token supplied in Step 5 is valid, the resource server gives access to the secured resource.