4

I have a question about PKCE (RFC 7636). OAuth clients that use the authorization code grant have two components: (1) the portion on the resource owner's device that initiates the authorization request and (2) a redirection endpoint on a server that can accept and send HTTPS messages.

The PKCE extension to OAuth has the clients do this:

  1. Generate a cryptographic random string called a code_verifier.
  2. Create a SHA-256 digest of the code_verifier and Base64-encode it. Send that along with the authorization request.
  3. When the client gets the authorization code and sends it to the token endpoint for an access token, include the original code_verifier value.

Step 2 happens on the resource owner's device. Once the resource owner has approved the request, his/her browser is redirected to the client's redirection endpoint. Step 3 happens at the redirection endpoint.

So the question is, how does the redirection endpoint know the code_verifier value? It was generated on the resource owner's device.

Grokify
  • 15,092
  • 6
  • 60
  • 81
Michael
  • 347
  • 2
  • 13

2 Answers2

2

So the question is, how does the redirection endpoint know the code_verifier value? It was generated on the resource owner's device.

Because the redirection endpoint effectively routes to an endpoint on the same device which called the authorise endpoint.

It may be registered as a loopback redirection, a app-claimed redirection or a custom URL scheme but the device will route the redirect to the appropriate app or the app will be listening on the appropriate port for loopbacks.

OAuth clients that use the authorization code grant have two components: (1) the portion on the resource owner's device that initiates the authorization request and (2) a redirection endpoint on a server that can accept and send HTTPS messages.

Confidential clients have a redirection endpoint on a server that can accept and send HTTPS messages.

Public clients do not - and native clients using PKCE are still public clients.

Community
  • 1
  • 1
iandayman
  • 4,357
  • 31
  • 38
1

To build on the information provided, PKCE is designed to ensure that the redirect URI routes back to the requesting app, and not a malicious app via an Authorization Code Interception Attack. In this scenario, the legitimate app will know the verifier but the malicious app will not know the verifier.

PKCE Legitimate App Flow

A legitimate app flow looks like the following where the authorization token request is redirected back to the SystemBrowser and then back to the originating NativeApp.

PKCE Legitimate app flow

Authorization Code Interception Attack

A malicious app can be introduced to the OS. With, or without PKCE, the native app can receive the authorization code, but it will not know the verifier and thus cannot complete the token exchange.

PKCE Malicious App Interception

Grokify
  • 15,092
  • 6
  • 60
  • 81
  • in your illustration of the PKCE flow : does the consent screen is mandatory ? Why there is not any reference about it in the RFC7636? – Dypso Mar 17 '19 at 09:32