3. Exchange the code 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.

Get access token

Congratulations, you have just obtained an access token

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

• 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.). It's encoded as a JSON Web Token (JWT), which can be decoded to reveal a header, payload, and signature. The payload of the JWT contains claims about the user and the authentication event. For example, the iss claim indicates the issuer of the token, the aud claim specifies the intended audience for the token, and the exp claim specifies the expiration time of the token. Want to see what's inside?

• 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.

• refresh_expires_in

  Indicates the number of seconds for which the refresh_token is valid. Once the refresh token is expired, the client will need to re-authenticate the user to get a new set of tokens.

• 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. Like the access_token, it's encoded as a JWT.

• 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.

• not-before-policy

  Specifies a time before which the token should not be accepted. A value of 0 implies the token can be immediately used.

• session_state

  Represents the state of the user's session at the Authorization Server. This is the same value that could was returned during the Authorization Code Flow in the session_state parameter. It can be used in scenarios like OpenID Connect session management to monitor the user's session.

• 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. Client application would now be able to request resources on users behalf without having to transfer his credentials with each request.