4. Exchange the code and code verifier for token

Now that we have the authorization code, we can exchange it for an access token. This is done by sending a POST request to the token endpoint.

With body data:

Let's break it down...

• The token endpoint URL

• grant_type=

  The grant type, in this case authorization_code

• client_id=

  Client ID of the application. This is a public identifier for the client, and it is used by the authorization server to identify the application when redirecting the user back to the client.

• redirect_uri=

  The redirect URI

• code=

  This is the authorization code we got in the previous step and is used to obtain the access token.

• code_verifier=

  This is the code verifier we generated in the first step. It is used to verify the identity of the client.

Get access token

Congratulations, you have just obtained an access token

Let's break down what we have received...

• token_type

  Indicates the type of token issued. In OAuth 2.0, the common type is "Bearer", which means that whoever bears the token can access the resources.

• expires_in

  Indicates the number of seconds for which the access_token is valid. After this time, the access_token will expire and a new one must be obtained.

• access_token

  This is the actual access token, which allows the client application to access the user's protected resources on the resource server (e.g., user profile, photos, etc.).

• refresh_token

  Used to obtain a new access_token when the current one expires. This allows the client to get a new access_token without requiring the user to log in again.

• scope

  Specifies the scopes granted by the user to the client application. Scopes determine the permissions associated with the access_token. Here, the granted scopes are email, offline_access, and profile. This means that with the provided access_token, the client application can access the user's email and profile information and is also granted offline access (typically used in conjunction with refresh tokens).

And this concludes the Authorization Code Flow with PKCE. Client application would now be able to request resources on users behalf without having to transfer his credentials with each request.