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,
So in the above 12 Steps, after Step 5 we may have an Application-in-Middle Attack(similar to Man-in-Middle Attack).
To avoid what is happening in above image we use PKCE specification,
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,
@Anil Sagar @Dino @arghya das @Maruti Chand
Solved! Go to Solution.
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.
Correct, Apigee Edge does not have a built-in PKCE mechanism.
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.
Good luck!
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.
Correct, Apigee Edge does not have a built-in PKCE mechanism.
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.
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.
User | Count |
---|---|
7 | |
2 | |
2 | |
1 | |
1 |