Authorization Code Exchange


The native app will then exchange the authorization code for an access token. In addition to the parameters defined in Authorization Code Request, the client will also send the code_verifier parameter. A complete access token request will include the following parameters:

  • grant_type=authorization_code – Indicates the grant type of this token request
  • code – The client will send the authorization code it obtained in the redirect
  • redirect_uri – The redirect URL that was used in the initial authorization request
  • client_id – The application’s registered client ID
  • code_verifier – The code verifier for the PKCE request, that the app originally generated before the authorization request.

In addition to validating the standard parameters, the authorization server will also validate the code_verifier in the request. Since the code_challenge and code_challenge_method were associated with the authorization code initially, the server should already know which method (plain or SHA256) to use to verify the code_verifier.

If the method is plain, then the authorization server needs only to check that the provided code_verifier matches the expected code_challenge string.

If the method is S256, then the authorization server should take the provided code_verifier and transform it using the same method the client will have used initially. This means calculating the SHA256 hash of the verifier and base64-url-encoding it, then comparing it to the stored code_challenge string.

If the verifier matches the expected value, then the server can continue on as normal, issuing an access token and responding appropriately. If there is a problem, then the server responds with an invalid_grant error.

The PKCE extension does not add any new responses, so clients can always use the PKCE extension even if an authorization server does not support it.