Hi, I have a few comments regarding the Proof Key for Code Exchange spec:
1. I wonder how exactly PKCE guarantees the protection for native apps in the context of generic OAuth 2 flow with an external browser, considering that a malicious app can initiate an authz request itself? More precisely, I believe there are two cases PKCE doesn't cover: - Malicious app generates its own code_verifier and opens an authz request in an external browser, which allows it to follow "1.1. Protocol Flow", eavesdrop the code at the callback uri it hijacked, and exchange it for token - Malicious app abuses the "5. Compatibility" section by initiating authz request without code_verifier for clients not supporting this extension, which allows it to just eavesdrop the code at the callback uri it hijacked, and exchange it for token By using parameter such as "immediate=true" / "display=none" app can even make authz request undetectable as it would silently succeed for previously TOSed apps and considering an existing browser session on provider. 2. Is it actually meant to be a sufficient protection to just follow PKCE in the generic OAuth 2 flow case for public clients (vs. using PKCE together with other improvements, such as with native apps sso flow http://www.thread-safe.com/2015/01/napps-high-level-flow-for-ios.html)? 3. What is meant by a "secure API" in the following claim from the "1. Introduction": "Step (1) happens through a secure API that cannot be intercepted, though it may potentially be observed in advanced attack scenarios."? Thanks, Andrey
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
