Understanding OAuth with PKCE

Notes on trying to understand OAuth with PKCE

Why

• This standard is designed to prevent the **prevent the Authorization Code Interception Attack**.
• The attack works like this
• A malicious app on the user's device (or malware intercepting network traffic, or exploiting custom URI schemes) could potentially **intercept the `authorization_code`** during the redirection step (Step 3).
• Since public clients often don't use a `client_secret` for authentication during the token exchange (because they can't keep it secret), the attacker could then take the intercepted `code` and exchange it for an `access_token` themselves (Step 4), effectively impersonating the user within your application.
  

Process

• PKCE introduces a dynamic, one-time proof that links the initial authorization request to the final token exchange request. It works like this:
• Client (SPA typically use a backend, this backend becomes the client responsible for auth) creates a secret code-verifier, a cryptographic random string
• This code verifier is kept a secret by our application
• Client now creates a challenge (SHA - 256 recommended)
• Client initiates the OAuth flow by sending the following params
  • code-challenge
  • code-challenge-method (S256 or Plain)
  • Auth server notes down this challenge and associates it with the auth code and sends redirects back to the redirect uri
  • Client recieves the auth code and needs to associate the code-verifier along with the request for the token exchange
• The auth server recieves the code-verifier and verifies it against the code-challenge by applying the specified transformation (SHA-256).
• If the result matches, we have verified that this request was generated by a trusty client.