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