OAuth 2.0 for Native Apps

Note: This ballot was opened for revision 10 and is now closed.

(Kathleen Moriarty) Yes

(Alia Atlas) No Objection

Deborah Brungard No Objection

Ben Campbell No Objection

Comment (2017-05-23 for -11)
I agree with Adam's general sentiment about detection of bad behavior vs asking people not to be bad.

-8 and it's children: There seems to be a lot of duplication (including duplication of normative language) between the security considerations and the rest of the document.

- 8.7: This section seems to argue against using in-app browser tabs in the first place. If there is no good way for the user to tell the difference between that and an imbedded UA, then maybe we should train users to be suspicious of any in-app presentation of the authorization request? The last paragraph seems to be founded on a mismatch between user needs and typical user sophistication.

(Benoit Claise) No Objection

Alissa Cooper No Objection

Spencer Dawkins No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2017-05-24 for -11)
Thanks to Zitao Wang (Michael) for the OpsDir review, and William for addressing the comments...

Mirja Kühlewind No Objection

Comment (2017-05-22 for -11)
Quick question just to double-check: should this document update RFC6749?

Terry Manderson No Objection

Alexey Melnikov No Objection

Comment (2017-05-24 for -11)
A couple of nits:

8.2.  OAuth Implicit Grant Authorization Flow

   The OAuth 2.0 implicit grant authorization flow as defined in
   Section 4.2 of OAuth 2.0 [RFC6749] generally works with the practice
   of performing the authorization request in the browser, and receiving
   the authorization response via URI-based inter-app communication.
   However, as the Implicit Flow cannot be protected by PKCE (which is a
   required in Section 8.1), the use of the Implicit Flow with native

NOT RECOMMENDED is not actually a construct allowed by RFC 2119, I think you should reword it using "SHOULD NOT".

It would be good to add RFC reference for HTTPS URIs.

Eric Rescorla No Objection

Comment (2017-05-23 for -11)
Document: draft-ietf-oauth-native-apps-11.txt

S 7.
   To fully support this best practice, authorization servers MUST
   support the following three redirect URI options.  Native apps MAY
   use whichever redirect option suits their needs best, taking into
   account platform specific implementation details.

It's not entirely clear from this text what "support" means. Would
just echoing whatever redirect URI the client provided count as

S 7.2.

   App-claimed HTTPS redirect URIs have some advantages in that the
   identity of the destination app is guaranteed by the operating
   system.  For this reason, they SHOULD be used in preference to the
   other redirect options for native apps where possible.

You should probably be clearer on who this guarantee is provided to.
And I assume this SHOULD is directed to app authors?

   Claimed HTTPS redirect URIs function as normal HTTPS redirects from
   the perspective of the authorization server, though as stated in
   Section 8.4, it is REQUIRED that the authorization server is able to
   distinguish between public native app clients that use app-claimed
   HTTPS redirect URIs and confidential web clients.

S 8.4 doesn't seem clear on how one makes this distinction. Is
it just a matter of remembering what the app author told you?

S 8.1.
   As most forms of inter-app URI-based communication send data over
   insecure local channels, eavesdropping and interception of the
   authorization response is a risk for native apps.  App-claimed HTTPS
   redirects are hardened against this type of attack due to the
   presence of the URI authority, but they are still public clients and
   the URI is still transmitted over local channels with unknown
   security properties.

I'm probably missing something, but I'm not sure what this last
sentence means. Is the channel here the one that kicks off the
native app with the HTTPS URI as the target?

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2017-05-22 for -11)
The thesis of this document seems to be that bad actors can access authentication information that gives them broader or more durable authorization than is intended; and appears to want to mitigate this predominantly with a single normative statement in a BCP telling potential bad actors to stop doing the one thing that enables their shenanigans.  For those familiar with the animated series "The Tick," it recalls the titular character yelling "Hey! You in the pumps! I say to you: stop being bad!" -- which, of course, is insufficient to achieve the desired effect.

I see that there is nevertheless "strong consensus" to publish the document; in which case, I would encourage somewhat more detail around what the rest of the ecosystem -- and the authentication server in particular -- can do to mitigate the ability of such bad actors. Specifically, section 8.1 has a rather hand-wavy suggestion that authorization endpoints "MAY take steps to detect and block authorization requests in embedded user agents," without offering up how this might be done. The problem is that that the naïve ways of doing this (UA strings?) are going to be easy to circumvent, and the more advanced ones (say, instructing users to log in using a non-OAuth flow if the auth endpoint detects absolutely no cookies associated with its origin) will have interactions that probably warrant discussion in this document. (For example, such an approach -- while potentially effective -- would interact very poorly with the "SSO mode" described in section B.3; although I think that recommending the use of "SSO mode" should be removed for other reasons, described below).


Specific comments follow

The terminology section makes distinctions about cookie handling and content access in generic definitions (embedded versus external UAs, for example) but doesn't do the same for specific technologies. It is probably worthwhile noting that the "in-app browser tab" prevents apps from accessing cookies and content, while the "web-view" does not (I had to infer these facts from statements much later in the document).

Section 7.3 gives examples of IPv4 and IPv6 addresses for loopback. While I'm sympathetic to the deployment challenges inherent in getting entire network paths to upgrade to IPv6, this text discusses loopback exclusively, which means that only the local operating system needs to support IPv6. Since all modern operating systems have supported IPv6 for well over a decade, I suggest that the use of IPv4 addresses for this purpose should be explicitly deprecated, so as to avoid unnecessary transition pain in the future. Minimally, the example needs to be replaced or supplemented with an IPv6 example, as per <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>: "We recommend that existing standards be reviewed to ensure they... use IPv6 examples."

Section 8.1 makes the statement that "Loopback IP based redirect URIs may be susceptible to interception by other apps listening on the same loopback interface." That's not how TCP listener sockets work: for any given IP address, they guarantee single-process access to a port at any one time. (Exceptions would include processes with root access, but an attacking process with that level of access is going to be impossible to defend against). While mostly harmless, the statement appears to be false on its face, and should be removed or clarified.

Section 8.4 indicates that loopback redirect URIs are allowed to vary from their registered value in port number only. If you decide not to deprecate the use of IPv4 loopback, I imagine that servers should also treat [::1] identical to 127.0.01 for this purpose as well.

Section 8.7 claims that users are likely to be suspicious of a sign-in request when they should have already been signed in, and goes on to claim that they will distinguish between completely-logged-out states and logged-in-but-needing-reauth states, and may even take evasive action based on associated suspicion. Based on what I know of user research for security indicators, the chances of these statements being true for any non-trivial portion of any user population is basically zero. I propose that this section simply highlight that this is effectively an intractable problem from the client end, without any illusions that users have the ability to distinguish between the two circumstances, and that authentication servers must be extra vigilant in detecting and avoiding these kinds of attacks.

Section 8.11, third paragraph talks about keystroke logging; in practice, the attack here is far easier than that, as I believe that applications that embed a web view can simply extract authentication-related material directly from the DOM.

Section B.2 uses the phrase "Android Implicit Intends" where I believe it means "Android Implicit Intents."

Section B.3 describes the use of a "Web Authentication Broker" in SSO mode, which provides an isolated authentication context. If the section 8.7 text regarding user detection of nefarious application behavior in the form of web-view embedding is not removed, this needs a very clear treatment of how users might be expected to distinguish between that behavior and the SSO mode behavior. On casual examination, it seems that there would be no way to do so. I'll note that this BCP also promotes the "already logged in" behavior as being a key benefit to OAuth (cf. the third paragraph of Section 4), which the described behavior seems to mostly defeat. I would strongly suggest either removing discussion of using this mode, or deprecating it in favor of the user's preferred web browser, so as to obtain the advantages described in section 4.