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