< draft-ietf-oauth-native-apps-00.txt		draft-ietf-oauth-native-apps-01.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: August 7, 2016 Ping Identity		Expires: September 21, 2016 Ping Identity
	February 04, 2016		March 20, 2016
	OAuth 2.0 for Native Apps		OAuth 2.0 for Native Apps
	draft-ietf-oauth-native-apps-00		draft-ietf-oauth-native-apps-01
	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 such as the system browser (including		through external user-agents such as the system browser (including
	via an in-app browser tab). This specification details the security		via an in-app browser tab). This specification details the security
	and usability reasons why this is the case, and how native apps and		and usability reasons why this is the case, and how native apps and
	authorization servers can implement this best practice.		authorization servers can implement 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 August 7, 2016.		This Internet-Draft will expire on September 21, 2016.
	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 3, line 26 ¶		skipping to change at page 3, line 26 ¶
	In addition to the terms defined in referenced specifications, this		In addition to the terms defined in referenced specifications, this
	document uses the following terms:		document uses the following terms:
	"app" A native application, such as one on a mobile device or		"app" A native application, such as one on a mobile device or
	desktop operating system.		desktop operating system.
	"app store" An ecommerce store where users can download and purchase		"app store" An ecommerce store where users can download and purchase
	apps. Typically with quality-control measures to protect users		apps. Typically with quality-control measures to protect users
	from malicious developers.		from malicious developers.
			"authz" Abbreviation of "authorization".
	"system browser" The operating system's default browser, typically		"system browser" The operating system's default browser, typically
	pre-installed as part of the operating system, or installed and		pre-installed as part of the operating system, or installed and
	set as default by the user.		set as default by the user.
	"browser tab" An open page of the system browser. Browser typically		"browser tab" An open page of the system browser. Browser typically
	have multiple "tabs" representing various open pages.		have multiple "tabs" representing various open pages.
	"in-app browser tab" A full page browser with limited navigation		"in-app browser tab" A full page browser with limited navigation
	capabilities that is displayed inside a host app, but retains the		capabilities that is displayed inside a host app, but retains the
	full security properties and authentication state of the system		full security properties and authentication state of the system
	skipping to change at page 4, line 37 ¶		skipping to change at page 4, line 40 ¶
	present the system browser without the user switching context		present the system browser without the user switching context
	something that could previously only be achieved by a web-view on		something that could previously only be achieved by a web-view on
	most platforms.		most platforms.
	Inter-process communication, such as OAuth flows between a native app		Inter-process communication, such as OAuth flows between a native app
	and the system browser can be achieved through URI-based		and the system browser can be achieved through URI-based
	communication. As this is exactly how OAuth works for web-based		communication. As this is exactly how OAuth works for web-based
	OAuth flows between RP and IDP websites, OAuth can be used for native		OAuth flows between RP and IDP websites, OAuth can be used for native
	app auth with very little modification.		app auth with very little modification.
	1.3.1. Authorization Flow for Native Apps		1.3.1. Authorization Flow for Native Apps Using App-Claimed URI Schemes
	+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+		+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
	| User Device |		| User Device |
	| |		| |
	| +---------------------------+ | +-----------+		| +---------------------------+ | +-----------+
	| | | | (4) Authz Grant | |		| | | | (5) Authz Code | |
	| | Client App |----------------------->| Authz |		| | Client App |----------------------->| Token |
	| | |<-----------------------| Server |		| | |<-----------------------| Endpoint |
	| +---------------------------+ | (5) Access Token | |		| +---------------------------+ | (6) Access Token, | |
	| | ^ | +-----------+		| | ^ | Refresh Token +-----------+
	| | | |		| | | |
	| | | |		| | | |
	| | (1) | (3) |		| | (1) | (4) |
	| | Authz | Authz |		| | Authz | Authz |
	| | Request | Grant |		| | Request | Code |
	| | "https://" | "app:/" |		| | | |
	| | | |		| | | |
	| v | |		| v | |
	| +---------------------------+ | +-----------+		| +---------------------------+ | +---------------+
	| | | | (2) User | |		| | | | (2) Authz Request | |
	| | System Browser Tab | | authenticated | Identity |		| | In-app Browser Tab |--------------------->| Authorization |
	| | |<---------------------->| Provider |		| | |<---------------------| Endpoint |
	| +---------------------------+ | | |		| +---------------------------+ | (3) Authz Code | |
	| | +-----------+		| | +---------------+
	+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+		+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
	Figure 1: Native App Authorization via External User-agent		Figure 1: Native App Authorization via External User-agent
	Figure 1 illustrates the interaction of the native app with the		Figure 1 illustrates the interaction of the native app with the
	system browser to authorize the user via an external user-agent.		system browser to authorize the user via an external user-agent.
	1) The client app opens a system browser with the authorization		1) The client app opens an in-app browser tab or system browser with
	request (e.g. https://idp.example.com/oauth2/auth...)		the authorization request.
	2) Server authenticates the end-user, potentially chaining to another		2) Authorization endpoint receives the authorization request, and
	authentication system, and issues Authorization Code Grant on		processes it, typically by authenticating the end-user and
	success		obtaining an authorization decision. How the authorization server
			authenticates the end-user is out of scope for this specification,
			but can potentially involve chaining to other authentication
			systems using various authentication protocols.
	3) Browser switches focus back to the client app using a URI with a		3) Authorization server issues an authorization code to a redirect
	custom scheme or claimed HTTPS URL, passing the code as a URI		URI that utilizes an app-claimed URI scheme.
	parameter.
	4) Client presents the OAuth 2.0 authorization code and PKCE		4) In-app browser tab validates the URI scheme of the redirect, and
	[RFC7636] proof of possession verifier.		forwards the authorization response to the app which claims it.
	5) Server issues the tokens requested.		5) Client app presents the authorization code at the Token endpoint.
			6) Token endpoint validates the authorization code and issues the
			tokens requested.
	2. Using Inter-app URI Communication for OAuth		2. Using Inter-app URI Communication for OAuth
	Just as URIs are used for OAuth 2.0 [RFC6749] on the web to initiate		Just as URIs are used for OAuth 2.0 [RFC6749] on the web to initiate
	the authorization request and return the authorization response to		the authorization request and return the authorization response to
	the requesting website, URIs can be used by native apps to initiate		the requesting website, URIs can be used by native apps to initiate
	the authorization request in the device's system browser and return		the authorization request in the device's system browser and return
	the response to the requesting native app.		the response to the requesting native app.
	By applying the same principles from the web to native apps, we gain		By applying the same principles from the web to native apps, we gain
	skipping to change at page 13, line 12 ¶		skipping to change at page 13, line 12 ¶
	may also be viable for secure and usable OAuth. This document makes		may also be viable for secure and usable OAuth. This document makes
	no comment on those patterns.		no comment on those patterns.
	7. Client Authentication		7. Client Authentication
	Secrets that are statically included as part of an app distributed to		Secrets that are statically included as part of an app distributed to
	multiple users should not be treated as confidential secrets, as one		multiple users should not be treated as confidential secrets, as one
	user may inspect their copy and learn the secret of all users. For		user may inspect their copy and learn the secret of all users. For
	this reason it is NOT RECOMMENDED for authorization servers to		this reason it is NOT RECOMMENDED for authorization servers to
	require client authentication of native apps using a secret shared by		require client authentication of native apps using a secret shared by
	multiple installs of the app, as this serves no value beyond client		multiple installs of the app, as this serves little value beyond
	identification which is already provided by the client_id request		client identification which is already provided by the client_id
	parameter. If an authorization server requires a client secret for		request parameter. If an authorization server requires a client
	native apps, it MUST NOT assume that it is actually secret, unless		secret for native apps, it MUST NOT assume that it is actually
	some method is being used to dynamically provision a unique secret to		secret, unless some method is being used to dynamically provision a
	each installation.		unique secret to each installation.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",		[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
	RFC 6749, DOI 10.17487/RFC6749, October 2012,		RFC 6749, DOI 10.17487/RFC6749, October 2012,
	<http://www.rfc-editor.org/info/rfc6749>.		<http://www.rfc-editor.org/info/rfc6749>.
	[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key		[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
End of changes. 11 change blocks.
	46 lines changed or deleted		53 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/