draft-ietf-oauth-native-apps-05.txt   draft-ietf-oauth-native-apps-06.txt 
OAuth Working Group W. Denniss OAuth Working Group W. Denniss
Internet-Draft Google Internet-Draft Google
Intended status: Best Current Practice J. Bradley Intended status: Best Current Practice J. Bradley
Expires: April 24, 2017 Ping Identity Expires: May 17, 2017 Ping Identity
October 21, 2016 November 13, 2016
OAuth 2.0 for Native Apps OAuth 2.0 for Native Apps
draft-ietf-oauth-native-apps-05 draft-ietf-oauth-native-apps-06
Abstract Abstract
OAuth 2.0 authorization requests from native apps should only be made OAuth 2.0 authorization requests from native apps should only be made
through external user-agents, primarily the user's browser. This through external user-agents, primarily the user's browser. This
specification details the security and usability reasons why this is specification details the security and usability reasons why this is
the case, and how native apps and authorization servers can implement the case, and how native apps and authorization servers can implement
this best practice. this best practice.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2017. This Internet-Draft will expire on May 17, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 8, line 13 skipping to change at page 8, line 13
processes the authorization response like any OAuth client. processes the authorization response like any OAuth client.
7.1.1. Custom URI Scheme Namespace Considerations 7.1.1. Custom URI Scheme Namespace Considerations
When choosing a URI scheme to associate with the app, apps MUST use a When choosing a URI scheme to associate with the app, apps MUST use a
URI scheme based on a domain name under their control, expressed in URI scheme based on a domain name under their control, expressed in
reverse order, as recommended by Section 3.8 of [RFC7595] for reverse order, as recommended by Section 3.8 of [RFC7595] for
private-use URI schemes. private-use URI schemes.
For example, an app that controls the domain name "app.example.com" For example, an app that controls the domain name "app.example.com"
can use "com.example.app:/" as their custom scheme. Some can use "com.example.app:" as their custom scheme. Some
authorization servers assign client identifiers based on domain authorization servers assign client identifiers based on domain
names, for example "client1234.usercontent.example.net", which can names, for example "client1234.usercontent.example.net", which can
also be used as the domain name for the custom scheme, when reversed also be used as the domain name for the custom scheme, when reversed
in the same manner, for example "net.example.usercontent.client1234". in the same manner, for example "net.example.usercontent.client1234".
URI schemes not based on a domain name (for example "myapp:/") MUST URI schemes not based on a domain name (for example "myapp:") MUST
NOT be used, as they are not collision resistant, and don't comply NOT be used, as they are not collision resistant, and don't comply
with Section 3.8 of [RFC7595]. with Section 3.8 of [RFC7595].
Care must be taken when there are multiple apps by the same publisher Care must be taken when there are multiple apps by the same publisher
that each URI scheme is unique within that group. On platforms that that each URI scheme is unique within that group. On platforms that
use app identifiers that are also based on reverse order domain use app identifiers that are also based on reverse order domain
names, those can be re-used as the custom URI scheme for the OAuth names, those can be re-used as the custom URI scheme for the OAuth
redirect. redirect.
In addition to the collision resistant properties, basing the URI In addition to the collision resistant properties, basing the URI
skipping to change at page 8, line 42 skipping to change at page 8, line 42
claim the same custom scheme (such as if an app is acting claim the same custom scheme (such as if an app is acting
maliciously). For example, if two apps claimed "com.example.app:", maliciously). For example, if two apps claimed "com.example.app:",
the owner of "example.com" could petition the app store operator to the owner of "example.com" could petition the app store operator to
remove the counterfeit app. This petition is harder to prove if a remove the counterfeit app. This petition is harder to prove if a
generic URI scheme was used. generic URI scheme was used.
7.2. App-claimed HTTPS URI Redirection 7.2. App-claimed HTTPS URI Redirection
Some operating systems allow apps to claim HTTPS URLs in their Some operating systems allow apps to claim HTTPS URLs in their
domains. When the browser encounters a claimed URL, instead of the domains. When the browser encounters a claimed URL, instead of the
page being loaded in the browser, the native app is launched instead page being loaded in the browser, the native app is launched with the
with the URL supplied as a launch parameter. URL supplied as a launch parameter.
App-claimed HTTPS redirect URIs have some advantages in that the App-claimed HTTPS redirect URIs have some advantages in that the
identity of the destination app is guaranteed by the operating identity of the destination app is guaranteed by the operating
system. Due to this reason, they SHOULD be used over the other system. Due to this reason, they SHOULD be used over the other
redirect choices for native apps where possible. redirect choices for native apps where possible.
App-claimed HTTPS redirect URIs function as normal HTTPS redirects App-claimed HTTPS redirect URIs function as normal HTTPS redirects
from the perspective of the authorization server, though it is from the perspective of the authorization server, though it is
RECOMMENDED that the authorization server is able to distinguish RECOMMENDED that the authorization server is able to distinguish
between public native app clients that use app-claimed HTTPS redirect between public native app clients that use app-claimed HTTPS redirect
skipping to change at page 9, line 30 skipping to change at page 9, line 30
For loopback IP redirect URIs, the authorization server MUST allow For loopback IP redirect URIs, the authorization server MUST allow
any port to be specified at the time of the request, to accommodate any port to be specified at the time of the request, to accommodate
clients that obtain an available port from the operating system at clients that obtain an available port from the operating system at
the time of the request. Other than that, the redirect is be treated the time of the request. Other than that, the redirect is be treated
like any other. like any other.
8. Security Considerations 8. Security Considerations
8.1. Embedded User-Agents 8.1. Embedded User-Agents
Embedded user-agents are an alternative method for authorization Embedded user-agents are an alternative method for authorizing native
native apps. They are however unsafe for use by third-parties to the apps. They are however unsafe for use by third-parties to the
authorization server by definition, as the app that hosts the authorization server by definition, as the app that hosts the
embedded user-agent can access the user's full authentication embedded user-agent can access the user's full authentication
credential, not just the OAuth authorization grant that was intended credential, not just the OAuth authorization grant that was intended
for the app. for the app.
In typical web-view based implementations of embedded user-agents, In typical web-view based implementations of embedded user-agents,
the host application can: log every keystroke entered in the form to the host application can: log every keystroke entered in the form to
capture usernames and passwords; automatically submit forms and capture usernames and passwords; automatically submit forms and
bypass user-consent; copy session cookies and use them to perform bypass user-consent; copy session cookies and use them to perform
authenticated actions as the user. authenticated actions as the user.
skipping to change at page 10, line 30 skipping to change at page 10, line 30
The redirect URI options documented in Section 7 share the benefit The redirect URI options documented in Section 7 share the benefit
that only a native app on the same device can receive the that only a native app on the same device can receive the
authorization code which limits the attack surface, however code authorization code which limits the attack surface, however code
interception by a native app other than the intended app may still be interception by a native app other than the intended app may still be
possible. possible.
A limitation of using custom URI schemes for redirect URIs is that A limitation of using custom URI schemes for redirect URIs is that
multiple apps can typically register the same scheme, which makes it multiple apps can typically register the same scheme, which makes it
indeterminate as to which app will receive the Authorization Code. indeterminate as to which app will receive the Authorization Code.
PKCE [RFC7636] details how this limitation can be used to execute a PKCE [RFC7636] details how this limitation can be used to execute a
code interception attack (see Figure 1). Loopback IP based redirect code interception attack (see Figure 1).
URIs may be susceptible to interception by other apps listening on
the same loopback interface. Loopback IP based redirect URIs may be susceptible to interception by
other apps listening on the same loopback interface.
As most forms of inter-app URI-based communication sends data over As most forms of inter-app URI-based communication sends data over
insecure local channels, eavesdropping and interception of the insecure local channels, eavesdropping and interception of the
authorization response is a risk for native apps. App-claimed HTTPS authorization response is a risk for native apps. App-claimed HTTPS
redirects are hardened against this type of attack due to the redirects are hardened against this type of attack due to the
presence of the URI authority, but they are still public clients and presence of the URI authority, but they are still public clients and
the URI is still transmitted over local channels with unknown the URI is still transmitted over local channels with unknown
security properties. security properties.
The Proof Key for Code Exchange by OAuth Public Clients (PKCE The Proof Key for Code Exchange by OAuth Public Clients (PKCE
 End of changes. 8 change blocks. 
13 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/