I believe that you're correct that the two cases you mention are not directly covered by PKCE.
Some kind of user interaction should be required at the AS for public clients to prevent undetectable authz requests (I think maybe Android even enforces it). https://tools.ietf.org/html/draft-ietf-oauth-native-apps-01 is a work in progress document that has effectually overtaken the native apps sso work that you'd linked to and describes some best practices for OAuth and native apps. That includes the use of PKCE in section 5.2 and section 5.4 is about needing user interaction when handling authz requests from non-verifiable clients. I realize I probably didn't exactly answer your questions but I hope that helps. On Tue, May 10, 2016 at 3:58 PM, isciurus <[email protected]> wrote: > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
