Authorization code grant with PKCE


The Authorization Code Flow with PKCE accepts a secret that is created by the application and is verified by the authorization server. This is known as the Code Verifier, and it’s used to create the Code Challenge which is sent over HTTPS to retrieve the authorization code.

For more in-depth implementation details, check out Authentication (Single-page application).
Why do we need to do this?

This is mainly because Native and Single-page apps (SPAs) cannot securely store the Client Secret. However, even server-side apps benefit greatly from this approach.

Fortunately, OAuth 2.0 has a flow for this very situation.

Freepik hacker icon

With this approach, if an attacker somehow intercepts the authorization code, they aren’t able to guess what the code_verifier is since, it is only stored locally by the app and not sent over the network.

With this authentication method, the calling app can proves that it is the legitimate owner of that authorization code, just as a client_secret proves a client is legitimate.


auth with pkce flow

  1. A user logs in from your app.

  2. Calling application generates the code_verifier

  3. Calling application hashes the code_verifier to create the code_challenge.

  4. ReachFive’s SDK redirects the user to the ReachFive Authorization Server /oauth/authorize endpoint with the code_challenge.

  5. ReachFive’s Authorization Server redirects the user to the login and auth prompt.

  6. The user authenticates through one of the login options.

    Users may see a consent page listing the permissions ReachFive will give to the regular web application.
  7. ReachFive’s Authorization Server stores the code_challenge and redirects the user back to the application with an authorization code.

    This is for one-time use only.
  8. ReachFive’s SDK sends the code as well as the code_verifier to the ReachFive Authorization Server /oauth/token endpoint.

  9. ReachFive’s Authorization Server verifies the code_challenge and code_verifier.

  10. ReachFive’s Authorization Server responds with an ID Token and Access Token.

    This could also be a refresh token.
  11. Your app can then use the Access Token to call the API to access information about the user.

  12. Your API responds with the requested data.

PKCE importance

The PKCE flow is relevant even for server-side integrations where the client_secret is used. Because servers are often stateless, when a server-side app receives an authorization code, it exchanges it at /oauth/token. Using PKCE in server-side apps ensures that only legitimate clients are able to exchange the code.