< draft-ietf-oauth-native-apps-06.txt		draft-ietf-oauth-native-apps-07.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: May 17, 2017 Ping Identity		Expires: July 21, 2017 Ping Identity
	November 13, 2016		January 17, 2017
	OAuth 2.0 for Native Apps		OAuth 2.0 for Native Apps
	draft-ietf-oauth-native-apps-06		draft-ietf-oauth-native-apps-07
	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 May 17, 2017.		This Internet-Draft will expire on July 21, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	8.11. Authorization Server Mix-Up Mitigation . . . . . . . . . 13		8.11. Authorization Server Mix-Up Mitigation . . . . . . . . . 13
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10.1. Normative References . . . . . . . . . . . . . . . . . . 14		10.1. Normative References . . . . . . . . . . . . . . . . . . 14
	10.2. Informative References . . . . . . . . . . . . . . . . . 15		10.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. Server Support Checklist . . . . . . . . . . . . . . 15		Appendix A. Server Support Checklist . . . . . . . . . . . . . . 15
	Appendix B. Operating System Specific Implementation Details . . 16		Appendix B. Operating System Specific Implementation Details . . 16
	B.1. iOS Implementation Details . . . . . . . . . . . . . . . 16		B.1. iOS Implementation Details . . . . . . . . . . . . . . . 16
	B.2. Android Implementation Details . . . . . . . . . . . . . 16		B.2. Android Implementation Details . . . . . . . . . . . . . 16
	B.3. Windows Implementation Details . . . . . . . . . . . . . 17		B.3. Windows Implementation Details . . . . . . . . . . . . . 17
	B.4. macOS Implementation Details . . . . . . . . . . . . . . 17		B.4. macOS Implementation Details . . . . . . . . . . . . . . 18
	B.5. Linux Implementation Details . . . . . . . . . . . . . . 17		B.5. Linux Implementation Details . . . . . . . . . . . . . . 18
	Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 18		Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The OAuth 2.0 [RFC6749] authorization framework documents two		The OAuth 2.0 [RFC6749] authorization framework documents two
	approaches in Section 9 for native apps to interact with the		approaches in Section 9 for native apps to interact with the
	authorization endpoint: an embedded user-agent, or an external user-		authorization endpoint: an embedded user-agent, or an external user-
	agent.		agent.
	skipping to change at page 16, line 21 ¶		skipping to change at page 16, line 21 ¶
	accurate at the time of publishing, but may change over time.		accurate at the time of publishing, but may change over time.
	It is expected that this OS-specific information will change, but		It is expected that this OS-specific information will change, but
	that the overall principles described in this document for using		that the overall principles described in this document for using
	external user-agents will remain valid.		external user-agents will remain valid.
	B.1. iOS Implementation Details		B.1. iOS Implementation Details
	Apps can initiate an authorization request in the browser without the		Apps can initiate an authorization request in the browser without the
	user leaving the app, through the SFSafariViewController class which		user leaving the app, through the SFSafariViewController class which
	implements the browser-view pattern. Safari can be used to handle		implements the in-app browser tab pattern. Safari can be used to
	requests on old versions of iOS without SFSafariViewController.		handle requests on old versions of iOS without
			SFSafariViewController.
	To receive the authorization response, both custom URI scheme		To receive the authorization response, both custom URI scheme
	redirects and claimed HTTPS links (known as Universal Links) are		redirects and claimed HTTPS links (known as Universal Links) are
	viable choices, and function the same whether the request is loaded		viable choices, and function the same whether the request is loaded
	in SFSafariViewController or the Safari app. Apps can claim Custom		in SFSafariViewController or the Safari app. Apps can claim Custom
	URI schemes with the "CFBundleURLTypes" key in the application's		URI schemes with the "CFBundleURLTypes" key in the application's
	property list file "Info.plist", and HTTPS links using the Universal		property list file "Info.plist", and HTTPS links using the Universal
	Links feature with an entitlement file and an association file on the		Links feature with an entitlement file and an association file on the
	domain.		domain.
	Universal Links are the preferred choice on iOS 9 and above due to		Universal Links are the preferred choice on iOS 9 and above due to
	the ownership proof that is provided by the operating system.		the ownership proof that is provided by the operating system.
	A complete open source sample is included in the AppAuth for iOS and		A complete open source sample is included in the AppAuth for iOS and
	macOS [AppAuth.iOSmacOS] library.		macOS [AppAuth.iOSmacOS] library.
	B.2. Android Implementation Details		B.2. Android Implementation Details
	Apps can initiate an authorization request in the browser without the		Apps can initiate an authorization request in the browser without the
	user leaving the app, through the Android Custom Tab feature which		user leaving the app, through the Android Custom Tab feature which
	implements the browser-view pattern. The user's default browser can		implements the in-app browser tab pattern. The user's default
	be used to handle requests when no browser supports Custom Tabs.		browser can be used to handle requests when no browser supports
			Custom Tabs.
	Android browser vendors should support the Custom Tabs protocol (by		Android browser vendors should support the Custom Tabs protocol (by
	providing an implementation of the "CustomTabsService" class), to		providing an implementation of the "CustomTabsService" class), to
	provide the in-app browser tab user experience optimization to their		provide the in-app browser tab user experience optimization to their
	users. Chrome is one such browser that implements Custom Tabs.		users. Chrome is one such browser that implements Custom Tabs.
	To receive the authorization response, custom URI schemes are broadly		To receive the authorization response, custom URI schemes are broadly
	supported through Android Implicit Intends. Claimed HTTPS redirect		supported through Android Implicit Intends. Claimed HTTPS redirect
	URIs through Android App Links are available on Android 6.0 and		URIs through Android App Links are available on Android 6.0 and
	above. Both types of redirect URIs are registered in the		above. Both types of redirect URIs are registered in the
	application's manifest.		application's manifest.
	A complete open source sample is included in the AppAuth for Android		A complete open source sample is included in the AppAuth for Android
	[AppAuth.Android] library.		[AppAuth.Android] library.
	B.3. Windows Implementation Details		B.3. Windows Implementation Details
	Apps can initiate an authorization request in the user's default		Universal Windows Platform (UWP) apps can use the Web Authentication
	browser using platform APIs for this purpose.		Broker API in SSO mode as an external user-agent for authorization
			flows, and all app types can open an authorization request in the
			user's default browser using platform APIs for opening URIs in the
			browser.
	The custom URI scheme redirect is a good choice for Universal Windows		The Web Authentication Broker when used in SSO mode is an external
	Platform (UWP) apps as it will open the app returning the user right		user-agent with an authentication context that is shared with all
	back where they were. Known on UWP as URI Activation, the scheme is		invocations of the broker but not the user's browser. Note that if
	limited to 39 characters, but may include the "." character, making		not used in SSO mode, the broker is an embedded user-agent, hence
	short reverse domain name based schemes (as recommended in		only operation in SSO mode is RECOMMENDED.
	Section 7.1.1) possible.
	The loopback redirect is the common choice for traditional desktop		To use the Web Authentication Broker in SSO mode, the redirect URI
	apps, listening on a loopback interface port is permitted by default		must be of the form "msapp://{appSID}" where "appSID" is the app's
	Windows firewall rules.		SID, which can be found in the app's registration information. While
			Windows enforces the URI authority on such redirects, ensuring only
			the app with the matching SID can receive the response on Windows,
			the URI scheme could be claimed by apps on other platforms without
			the same authority present, thus this redirect type should be treated
			similar to custom URI scheme redirects for security purposes.
	A complete open source sample is available [SamplesForWindows].		Both traditional and Universal Windows Platform (UWP) apps can
			perform authorization requests in the user's browser. Traditional
			apps typically use a loopback redirect to receive the authorization
			response, and listening on the loopback interface is allowed by
			default firewall rules. Universal Windows Platform (UWP) apps can
			use custom URI scheme redirects to receive the authorization
			response, which will bring the app to the foreground. Known on the
			platform as "URI Activation", the URI scheme is limited to 39
			characters in length, and may include the "." character, making short
			reverse domain name based schemes (as recommended in Section 7.1.1)
			possible.
			An open source sample demonstrating these patterns is available
			[SamplesForWindows].
	B.4. macOS Implementation Details		B.4. macOS Implementation Details
	Apps can initiate an authorization request in the user's default		Apps can initiate an authorization request in the user's default
	browser using platform APIs for this purpose.		browser using platform APIs for opening URIs in the browser.
	To receive the authorization response, custom URI schemes are are a		To receive the authorization response, custom URI schemes are are a
	good redirect URI choice on macOS, as the user is returned right back		good redirect URI choice on macOS, as the user is returned right back
	to the app they launched the request from. These are registered in		to the app they launched the request from. These are registered in
	the application's bundle information property list using the		the application's bundle information property list using the
	"CFBundleURLSchemes" key. Loopback IP redirects are another viable		"CFBundleURLSchemes" key. Loopback IP redirects are another viable
	option, and listening on the loopback interface is allowed by default		option, and listening on the loopback interface is allowed by default
	firewall rules.		firewall rules.
	A complete open source sample is included in the AppAuth for iOS and		A complete open source sample is included in the AppAuth for iOS and
End of changes. 12 change blocks.
	24 lines changed or deleted		46 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/