Why do we need PKCE specification (RFC 7636) in OAuth?

sidd-harth
Participant V

Hi guys, I have some basic queries regarding usage of PKCE(Proof Key for Code Exchange (RFC 7636) – PKCE pronounced as PIXY) with Authorization Code OAuth Flow.

Over simplified Auth Code flow,

5695-oauth-dance.png

So in the above 12 Steps, after Step 5 we may have an Application-in-Middle Attack(similar to Man-in-Middle Attack).

5696-pkce-1.png

To avoid what is happening in above image we use PKCE specification,

  • code_challenge parameter and code_challenge_method parameter to authorization requests using the authorization code flow, and
  • code_verifier parameter to token requests that correspond to the authorization requests.

5697-pkce-2.png

If PKCE is too be used in my Over simplified Auth Code flow,

At Step 2 – Client App re-directs User to Authorization Server along with an Code_verifier + Code_challenge

At Step 6 – Client makes a call with Authorization_Code + Code_verifier

So my questions are,

  1. Why do we need to use PKCE specification, when Client App is sending it's unique Client ID & Client secret at Step 6 of OAuth-Dance Image.
  2. I know that as of now Apigee doesnt have PKCE OOB policy. IMO it can be achieved by using extension policies.
  3. Does Apigee OAuth Server support PKCE specification?
  4. Is it a good practice to use PKCE as it adds addition complexity?

@Anil Sagar @Dino @arghya das @Maruti Chand

Solved Solved
1 5 6,242
1 ACCEPTED SOLUTION

  1. PKCE has been proposed as an enhancement to the security of the exchange. In the event that authz code is intercepted, without the PKCE, it is possible for an attacker to obtain a valid, new tokens. With the PKCE, this is prevented. The spec says this:

    OAuth 2.0 [RFC6749] public clients are susceptible to the authorization code interception attack.

    In this attack, the attacker intercepts the authorization code returned from the authorization endpoint within a communication path not protected by Transport Layer Security (TLS), such as inter- application communication within the client's operating system.

    Whether this enhancement is desirable from your point of view, depends on the security stance you have in your system.

  2. Correct, Apigee Edge does not have a built-in PKCE mechanism.

  3. Yes, and there is no need for a new "policy" to implement PKCE. It's a matter of
    1. client creates code verifier (a nonce), and a corresponding code challenge. The code challenge is just a sha256 hash of the verifier.
    2. Client sends the code challenge to server with initial authorization request.
    3. token dispensary (apigee edge) records the code challenge in cache, redirects to login server with a "session id" which is really just a cache key. The session id could just be the code challenge, which is a one-way hash. In other words the cache key and the cached value might be the same.
    4. the login-and-consent part of the 3-legged flow proceeds.
    5. When the login-and-consent form succeeds, the login server calls to Apigee Edge with the "session id" to retrieve an authorization code, to return to the client app.
    6. Apigee Edge generates a code and using the "session id", associates the code to the code challenge stored in cache.
    7. The app receives the 302 redirect and sends to Apigee Edge the code verifier and the code.
    8. Apigee Edge checks that the code and the code verifier are consistent. (= computes the sha256 of the verifier, and compares that to the stored challenge). If so, Apigee Edge issues a token. If not, 401

    All of this can be accomplished with PopulateCache, LookupCache, a JavaScript step for the sha256 calculation, and the existing builtin OAuth2.0 policies in Apigee Edge.

  4. Maybe. It depends on your view of how likely the attack is.

Good luck!

View solution in original post

5 REPLIES 5

  1. PKCE has been proposed as an enhancement to the security of the exchange. In the event that authz code is intercepted, without the PKCE, it is possible for an attacker to obtain a valid, new tokens. With the PKCE, this is prevented. The spec says this:

    OAuth 2.0 [RFC6749] public clients are susceptible to the authorization code interception attack.

    In this attack, the attacker intercepts the authorization code returned from the authorization endpoint within a communication path not protected by Transport Layer Security (TLS), such as inter- application communication within the client's operating system.

    Whether this enhancement is desirable from your point of view, depends on the security stance you have in your system.

  2. Correct, Apigee Edge does not have a built-in PKCE mechanism.

  3. Yes, and there is no need for a new "policy" to implement PKCE. It's a matter of
    1. client creates code verifier (a nonce), and a corresponding code challenge. The code challenge is just a sha256 hash of the verifier.
    2. Client sends the code challenge to server with initial authorization request.
    3. token dispensary (apigee edge) records the code challenge in cache, redirects to login server with a "session id" which is really just a cache key. The session id could just be the code challenge, which is a one-way hash. In other words the cache key and the cached value might be the same.
    4. the login-and-consent part of the 3-legged flow proceeds.
    5. When the login-and-consent form succeeds, the login server calls to Apigee Edge with the "session id" to retrieve an authorization code, to return to the client app.
    6. Apigee Edge generates a code and using the "session id", associates the code to the code challenge stored in cache.
    7. The app receives the 302 redirect and sends to Apigee Edge the code verifier and the code.
    8. Apigee Edge checks that the code and the code verifier are consistent. (= computes the sha256 of the verifier, and compares that to the stored challenge). If so, Apigee Edge issues a token. If not, 401

    All of this can be accomplished with PopulateCache, LookupCache, a JavaScript step for the sha256 calculation, and the existing builtin OAuth2.0 policies in Apigee Edge.

  4. Maybe. It depends on your view of how likely the attack is.

Good luck!

Hi @Dino,

Is there a GitHub reference implementation with PKCE in an authorization grant flow?

Regarding #1: "Why do we need to use PKCE specification, when Client App is sending it's unique Client ID & Client secret?"

The answer is that you do NOT need PKCE in this scenario. The title of RFC 7636 is "Proof Key for Code Exchange by OAuth Public Clients". Note "Public". RFC 6749 defines public client as

Clients incapable of maintaining the confidentiality of their
      credentials (e.g., clients executing on the device used by the
      resource owner, such as an installed native application or a web
      browser-based application), and incapable of secure client
      authentication via any other means.

So: PKCE is for public clients, and public clients do not use a client secret.

Native apps are public clients - they cannot be trusted with secrets. If you need more convincing on that point, see https://hackernoon.com/strengthening-oauth2-for-mobile-f4f3925dbf18 or https://www.oauth.com/oauth2-servers/mobile-and-native-apps/

or just web search "oauth native apps client secret"

yes, good point, absolutely correct.