[OAUTH-WG] Comments about PKCE / RFC7636

[isciurus]

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

[Brian Campbell]

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.

Post by isciurus
Hi,
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,
- 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.
"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
https://www.ietf.org/mailman/listinfo/oauth