The application 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
• client_secret (optional) – The application’s registered client secret if it was issued a secret
• code_verifier – The code verifier for the PKCE request, that the app originally generated before the authorization request.

Since the code_challenge and code_challenge_method were associated with the authorization code initially, the server should already know which method 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 hash method, 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.