< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/