idnits 2.17.1 draft-wdenniss-oauth-native-apps-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 04, 2016) is 2976 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6819' is defined on line 584, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group W. Denniss 3 Internet-Draft Google 4 Intended status: Best Current Practice J. Bradley 5 Expires: August 7, 2016 Ping Identity 6 February 04, 2016 8 OAuth 2.0 for Native Apps 9 draft-wdenniss-oauth-native-apps-02 11 Abstract 13 OAuth 2.0 authorization requests from native apps should only be made 14 through external user-agents such as the system browser (including 15 via an in-app browser tab). This specification details the security 16 and usability reasons why this is the case, and how native apps and 17 authorization servers can implement this best practice. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 7, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 55 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Using Inter-app URI Communication for OAuth . . . . . . . . . 6 58 3. Initiating the Authorization Request . . . . . . . . . . . . 6 59 4. Receiving the Authorization Response . . . . . . . . . . . . 7 60 4.1. App-declared Custom URI Scheme Redirection . . . . . . . 7 61 4.2. App-claimed HTTPS URI Redirection . . . . . . . . . . . . 9 62 4.3. Localhost-based URI Redirection . . . . . . . . . . . . . 9 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 5.1. Embedded User-Agents . . . . . . . . . . . . . . . . . . 10 65 5.2. Protecting the Authorization Code . . . . . . . . . . . . 11 66 5.3. Phishing . . . . . . . . . . . . . . . . . . . . . . . . 12 67 5.4. Limitations of Non-verifiable Clients . . . . . . . . . . 12 68 6. Other External User Agents . . . . . . . . . . . . . . . . . 12 69 7. Client Authentication . . . . . . . . . . . . . . . . . . . . 13 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 72 8.2. Informative References . . . . . . . . . . . . . . . . . 13 73 Appendix A. Operating System Specific Implementation Details . . 15 74 A.1. iOS Implementation Details . . . . . . . . . . . . . . . 15 75 A.2. Android Implementation Details . . . . . . . . . . . . . 15 76 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 The OAuth 2.0 [RFC6749] authorization framework, documents two 82 approaches in Section 9 for native apps to interact with the 83 authorization endpoint: via an embedded user-agent, or an external 84 user-agent. 86 This document recommends external user-agents like in-app browser 87 tabs as the only secure and usable choice for OAuth. It documents 88 how native apps can implement authorization flows with such agents, 89 and the additional requirements of authorization servers needed to 90 support such usage. 92 1.1. Notational Conventions 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in Key 97 words for use in RFCs to Indicate Requirement Levels [RFC2119]. If 98 these words are used without being spelled in uppercase then they are 99 to be interpreted with their normal natural language meanings. 101 1.2. Terminology 103 In addition to the terms defined in referenced specifications, this 104 document uses the following terms: 106 "app" A native application, such as one on a mobile device or 107 desktop operating system. 109 "app store" An ecommerce store where users can download and purchase 110 apps. Typically with quality-control measures to protect users 111 from malicious developers. 113 "system browser" The operating system's default browser, typically 114 pre-installed as part of the operating system, or installed and 115 set as default by the user. 117 "browser tab" An open page of the system browser. Browser typically 118 have multiple "tabs" representing various open pages. 120 "in-app browser tab" A full page browser with limited navigation 121 capabilities that is displayed inside a host app, but retains the 122 full security properties and authentication state of the system 123 browser. Has different platform-specific product names, such as 124 SFSafariViewController on iOS 9, and Chrome Custom Tab on Android. 126 "Claimed HTTPS URL" Some platforms allow apps to claim a domain name 127 by hosting a file that proves the link between site and app. 128 Typically this means that URLs opened by the system will be opened 129 in the app instead of the browser. 131 "web-view" A web browser UI component that can be embedded in apps 132 to render web pages, used to create embedded user-agents. 134 "reverse domain name notation" A naming convention based on the 135 domain name system, but where where the domain components are 136 reversed, for example "app.example.com" becomes "com.example.app". 138 "custom URI scheme" A URI scheme (as defined by [RFC3986]) that the 139 app creates and registers with the OS (and is not a standard URI 140 scheme like "https:" or "tel:"). Requests to such a scheme 141 results in the app which registered it being launched by the OS. 142 For example, "myapp:", "com.example.myapp:" are both custom URI 143 schemes. 145 "inter-app communication" Communication between two apps on a 146 device. 148 "OAuth" In this document, OAuth refers to OAuth 2.0 [RFC6749]. 150 1.3. Overview 152 At the time of writing, many native apps are still using web-views, a 153 type of embedded user-agent, for OAuth. That approach has multiple 154 drawbacks, including the client app being able to eavesdrop user 155 credentials, and is a suboptimal user experience as the 156 authentication session can't be shared, and users need to sign-in to 157 each app separately. 159 OAuth flows between a native app and the system browser (or another 160 external user-agent) are more secure, and take advantage of the 161 shared authentication state to enable single sign-on. The in-app 162 browser tab pattern makes this approach even more viable, as apps can 163 present the system browser without the user switching context 164 something that could previously only be achieved by a web-view on 165 most platforms. 167 Inter-process communication, such as OAuth flows between a native app 168 and the system browser can be achieved through URI-based 169 communication. As this is exactly how OAuth works for web-based 170 OAuth flows between RP and IDP websites, OAuth can be used for native 171 app auth with very little modification. 173 1.3.1. Authorization Flow for Native Apps 174 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 175 | User Device | 176 | | 177 | +---------------------------+ | +-----------+ 178 | | | | (4) Authz Grant | | 179 | | Client App |----------------------->| Authz | 180 | | |<-----------------------| Server | 181 | +---------------------------+ | (5) Access Token | | 182 | | ^ | +-----------+ 183 | | | | 184 | | | | 185 | | (1) | (3) | 186 | | Authz | Authz | 187 | | Request | Grant | 188 | | "https://" | "app:/" | 189 | | | | 190 | v | | 191 | +---------------------------+ | +-----------+ 192 | | | | (2) User | | 193 | | System Browser Tab | | authenticated | Identity | 194 | | |<---------------------->| Provider | 195 | +---------------------------+ | | | 196 | | +-----------+ 197 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 199 Figure 1: Native App Authorization via External User-agent 201 Figure 1 illustrates the interaction of the native app with the 202 system browser to authorize the user via an external user-agent. 204 1) The client app opens a system browser with the authorization 205 request (e.g. https://idp.example.com/oauth2/auth...) 207 2) Server authenticates the end-user, potentially chaining to another 208 authentication system, and issues Authorization Code Grant on 209 success 211 3) Browser switches focus back to the client app using a URI with a 212 custom scheme or claimed HTTPS URL, passing the code as a URI 213 parameter. 215 4) Client presents the OAuth 2.0 authorization code and PKCE 216 [RFC7636] proof of possession verifier. 218 5) Server issues the tokens requested. 220 2. Using Inter-app URI Communication for OAuth 222 Just as URIs are used for OAuth 2.0 [RFC6749] on the web to initiate 223 the authorization request and return the authorization response to 224 the requesting website, URIs can be used by native apps to initiate 225 the authorization request in the device's system browser and return 226 the response to the requesting native app. 228 By applying the same principles from the web to native apps, we gain 229 similar benefits like the usability of a single sign-on session, and 230 the security by a separate authentication context. It also reduces 231 the implementation complexity by reusing the same flows as the web, 232 and increases interoperability by relying on standards-based web 233 flows that are not specific to a particular platform. 235 It is RECOMMENDED that native apps use the URI-based communication 236 functionality of the operating system to perform OAuth flows in an 237 external user-agent, typically the system browser. 239 For usability, it is RECOMMENDED that native apps perform OAuth using 240 the system browser by presenting an in-app browser tab where 241 possible. This affords the benefits of the system browser, while 242 allowing the user to remain in the app. 244 It is possible to create an external user-agent for OAuth that is a 245 native app provided by the authorization server, as opposed to the 246 system browser. This approach shares a lot of similarity with using 247 the system browser as both use URIs for inter-app communication and 248 is able to provide a secure, shared authentication session, and thus 249 MAY be used for secure native OAuth, applying most of the techniques 250 described here. However it is NOT RECOMMENDED due to the increased 251 complexity and requirement for the user to have the AS app installed. 252 While much of the advice and security considerations are applicable 253 to such clients, they are out of scope for this specification. 255 3. Initiating the Authorization Request 257 The authorization request is created as per OAuth 2.0 [RFC6749], and 258 opened in the system browser. Where the operating system supports 259 in-app browser tabs, those should be preferred over switching to the 260 system browser, to improve usability. 262 The function of the redirect URI for a native app authorization 263 request is similar to that of a web-based authorization request. 264 Rather than returning the authorization code to the OAuth client's 265 server, it returns it to the native app. The various options for a 266 redirect URI that will return the code to the native app are 267 documented in Section 4. Any redirect URI that allows the app to 268 receive the URI and inspect its parameters is viable. 270 4. Receiving the Authorization Response 272 There are three main approaches to redirection URIs for native apps: 273 custom URI schemes, app-claimed HTTP URI schemes, and 274 http://localhost redirects. 276 4.1. App-declared Custom URI Scheme Redirection 278 Most major mobile and desktop computing platforms support inter-app 279 communication via URIs by allowing apps to register custom URI 280 schemes. When the system browser or another app attempts to follow a 281 URI with a custom scheme, the app that registered it is launched to 282 handle the request. This document is only relevant on platforms that 283 support this pattern. 285 In particular, the custom URI scheme pattern is supported on the 286 mobile platforms Android [Android.URIScheme], iOS [iOS.URIScheme], 287 and Windows Phone [WindowsPhone.URIScheme]. Desktop operating 288 systems Windows [Windows.URIScheme] and OS X [OSX.URIScheme] also 289 support custom URI schemes. 291 4.1.1. Using Custom URI Schemes for Redirection 293 To perform an OAuth 2.0 Authorization Request on a supported 294 platform, the native app launches the system browser with a normal 295 OAuth 2.0 Authorization Request, but provides a redirection URI that 296 utilizes a custom URI scheme that is registered by the calling app. 298 When the authentication server completes the request, it redirects to 299 the client's redirection URI like it would any redirect URI, but as 300 the redirection URI uses a custom scheme, this results in the OS 301 launching the native app passing in the URI. The native app extracts 302 the code from the query parameters from the URI just like a web 303 client would, and exchanges the Authorization Code like a regular 304 OAuth 2.0 client. 306 4.1.2. Custom URI Scheme Namespace Considerations 308 When selecting which URI scheme to associate with the app, apps 309 SHOULD pick a scheme that is globally unique, and which they can 310 assert ownership over. 312 To avoid clashing with existing schemes in use, using a scheme that 313 follows the reverse domain name pattern applied to a domain under the 314 app publishers control is RECOMMENDED. Such a scheme can be based on 315 a domain they control, or the OAuth client identifier in cases where 316 the authorization server issues client identifiers that are also 317 valid DNS subdomains. The chosen scheme MUST NOT clash with any IANA 318 registered scheme [IANA.URISchemes]. You SHOULD also ensure that no 319 other app by the same publisher uses the same scheme. 321 Schemes using reverse domain name notation are hardened against 322 collision. They are unlikely to clash with an officially registered 323 scheme [IANA.URISchemes] or unregistered de-facto scheme, as these 324 generally don't include a period character, and are unlikely to match 325 your domain name in any case. They are guaranteed not to clash with 326 any OAuth client following these naming guidelines in full. 328 Some platforms use globally unique bundle or package names that 329 follow the reverse domain name notation pattern. In these cases, the 330 app SHOULD register that bundle id as the custom scheme. If an app 331 has a bundle id or package name that doesn't match a domain name 332 under the control of the app, the app SHOULD NOT register that as a 333 scheme, and instead create a URI scheme based off one of their domain 334 names. 336 For example, an app whose publisher owns the top level domain name 337 "example.com" can register "com.example.app:/" as their custom 338 scheme. An app whose authorization server issues client identifiers 339 that are also valid domain names, for example 340 "client1234.usercontent.idp.com", can use the reverse domain name 341 notation of that domain as the scheme, i.e. 342 "com.idp.usercontent.client1234:/". Each of these examples are URI 343 schemes which are likely to be unique, and where the publisher can 344 assert ownership. 346 As a counter-example, using a simple custom scheme like "myapp:/" is 347 not guaranteed to be unique and is NOT RECOMMENDED. 349 In addition to uniqueness, basing the URI scheme off a name that is 350 under the control of the app's publisher can help to prove ownership 351 in the event of a dispute where two apps register the same custom 352 scheme (such as if an app is acting maliciously). For example, if 353 two apps registered "com.example.app:", the true owner of 354 "example.com" could petition the app store operator to remove the 355 counterfeit app. This petition is harder to prove if a generic URI 356 scheme was chosen. 358 4.1.3. Registration of App Redirection URIs 360 As recommended in Section 3.1.2.2 of OAuth 2.0 [RFC6749], the 361 authorization server SHOULD require the client to pre-register the 362 redirection URI. This remains true for app redirection URIs that use 363 custom schemes. 365 Additionally, authorization servers MAY request the inclusion of 366 other platform-specific information, such as the app package or 367 bundle name, or other information used to associate the app that may 368 be useful for verifying the calling app's identity, on operating 369 systems that support such functions. 371 Authorizations servers SHOULD support the ability for native apps to 372 register Redirection URIs that utilize custom URI schemes. 373 Authorization servers SHOULD enforce the recommendation in 374 Section 4.1.2 that apps follow naming guidelines for URI schemes. 376 4.2. App-claimed HTTPS URI Redirection 378 Some operating systems allow apps to claim HTTPS URLs of their 379 domains. When the browser sees such a claimed URL, instead of the 380 page being loaded in the browser, the native app is launched instead 381 with the URL given as input. 383 Where the operating environment provided app-claimed HTTPS URIs in a 384 usable fashion, these URIs should be used as the OAuth redirect, as 385 they allow the identity of the destination app to be guaranteed by 386 the operating system. 388 Apps on platforms that allow the user to disable this functionality, 389 present it in a user-unfriendly way, or lack it altogether MUST 390 fallback to using custom URI schemes. 392 The authorization server MUST allow the registration of HTTPS 393 redirect URIs for non-confidential native clients to support app- 394 claimed HTTPS redirect URIs. 396 4.3. Localhost-based URI Redirection 398 More applicable to desktop operating systems, some environments allow 399 the app to create a local server and listen for redirect URIs that. 400 This is an acceptable redirect URI choice for native apps on 401 compatible platforms. 403 Authorization servers SHOULD support redirect URIs on the localhost 404 host, and HTTP scheme, that is redirect URIs beginning with 405 http://localhost (NB. in this case, HTTP is acceptable, as the 406 request never leaves the device). 408 When an app is registered with such a redirect, it SHOULD be able to 409 specify any port in the authorization request, meaning that a request 410 with http://localhost:*/* as the redirect should be considered valid. 412 5. Security Considerations 414 5.1. Embedded User-Agents 416 Embedded user-agents, commonly implemented with web-views, are an 417 alternative method for authorizing native apps. They are however 418 unsafe for use by third-parties by definition. They involve the user 419 signing in with their full login credentials, only to have them 420 downscoped to less powerful OAuth credentials. 422 Even when used by trusted first-party apps, embedded user-agents 423 violate the principle of least privilege by obtaining more powerful 424 credentials than they need, potentially increasing the attack 425 surface. 427 In typical web-view based implementations of embedded user-agents, 428 the host application can: log every keystroke entered in the form to 429 capture usernames and passwords; automatically submit forms and 430 bypass user-consent; copy session cookies and use them to perform 431 authenticated actions as the user. 433 Encouraging users to enter credentials in an embedded web-view 434 without the usual address bar and other identity features that 435 browsers have makes it impossible for the user to know if they are 436 signing in to the legitimate site, and even when they are, it trains 437 them that it's OK to enter credentials without validating the site 438 first. 440 Aside from the security concerns, web-views do not share the 441 authentication state with other apps or the system browser, requiring 442 the user to login for every authorization request and leading to a 443 poor user experience. 445 Due to the above, use of embedded user-agents is NOT RECOMMENDED, 446 except where a trusted first-party app acts as the external user- 447 agent for other apps, or provides single sign-on for multiple first- 448 party apps. 450 Authorization servers SHOULD consider taking steps to detect and 451 block logins via embedded user-agents that are not their own, where 452 possible. 454 5.2. Protecting the Authorization Code 456 A limitation of custom URI schemes is that multiple apps can 457 typically register the same scheme, which makes it indeterminate as 458 to which app will receive the Authorization Code Grant. This is not 459 an issue for HTTPS redirection URIs (i.e. standard web URLs) due to 460 the fact the HTTPS URI scheme is enforced by the authority (as 461 defined by [RFC3986]), the domain name system, which does not allow 462 multiple entities to own the same domain. 464 If multiple apps register the same scheme, it is possible that the 465 authorization code will be sent to the wrong app (generally the 466 operating system makes no guarantee of which app will handle the URI 467 when multiple register the same scheme). PKCE [RFC7636] details how 468 this limitation can be used to execute a code interception attack 469 (see Figure 1). This attack vector applies to public clients 470 (clients that are unable to maintain a client secret) which is 471 typical of most native apps. 473 While Section 4.1.2 details ways that this can be mitigated through 474 policy enforcement (through being able to report and have removed any 475 offending apps), we can also protect the authorization code grant 476 from being used in cases where it was intercepted. 478 The Proof Key for Code Exchange by OAuth Public Clients (PKCE 479 [RFC7636]) standard was created specifically to mitigate against this 480 attack. It is a Proof of Possession extension to OAuth 2.0 that 481 protects the code grant from being used if it is intercepted. It 482 achieves this by having the client generate a secret verifier which 483 it passes in the initial authorization request, and which it must 484 present later when redeeming the authorization code grant. An app 485 that intercepted the authorization code would not be in possession of 486 this secret, rendering the code useless. 488 Both the client and the Authorization Server MUST support PKCE 489 [RFC7636] to use custom URI schemes, or localhost redirects. 490 Authorization Servers SHOULD reject authorization requests using a 491 custom scheme, or localhost as part of the redirection URI if the 492 required PKCE parameters are not present, returning the error message 493 as defined in Section 4.4.1 of PKCE [RFC7636]. It is RECOMMENDED to 494 use PKCE [RFC7636] for app-claimed HTTPS redirect URIs, even though 495 these are not generally subject to interception, to protect against 496 attacks on inter-app communication. 498 5.3. Phishing 500 While in-app browser tabs provide a secure authentication context, as 501 the user initiates the flow from a native app, it is possible for 502 that native app to completely fake an in-app browser tab. 504 This can't be prevented directly - once the user is in the native 505 app, that app is fully in control of what it can render, however 506 there are several mitigating factors. 508 Importantly, such an attack that uses a web-view to fake an in-app 509 browser tab will always start with no authentication state. If all 510 native apps use the techniques described in this best practice, users 511 will not need to sign-in frequently and thus should be suspicious of 512 any sign-in request when they should have already been signed-in. 514 This is true even for authorization servers that require frequent or 515 occasional re-authentication, as such servers can preserve some user 516 identifiable information from the old request, like the email address 517 or avatar. To help mitigate against phishing, it is RECOMMENDED to 518 show the user some hint that they were previously logged in, as an 519 attacking app would not be capable of doing this. 521 Users who are particularly concerned about their security may also 522 take the additional step of opening the request in the system browser 523 from the in-app browser tab, and completing the authorization there, 524 as most implementations of the in-app browser tab pattern offer such 525 functionality. This is not expected to be common user behavior, 526 however. 528 5.4. Limitations of Non-verifiable Clients 530 As stated in Section 10.2 of RFC 6749, the authorization server 531 SHOULD NOT process authorization requests automatically without user 532 consent or interaction, except when the identity of the client can be 533 assured. Measures such as claimed HTTPS redirects can be used by 534 native apps to prove their identity to the authorization server, and 535 some operating systems may offer alternative platform-specific 536 identity features which may be used, as appropriate. 538 6. Other External User Agents 540 This best practice recommends a particular type of external user- 541 agent: the in-app browser tab. Other external user-agents patterns 542 may also be viable for secure and usable OAuth. This document makes 543 no comment on those patterns. 545 7. Client Authentication 547 Secrets that are statically included as part of an app distributed to 548 multiple users should not be treated as confidential secrets, as one 549 user may inspect their copy and learn the secret of all users. For 550 this reason it is NOT RECOMMENDED for authorization servers to 551 require client authentication of native apps using a secret shared by 552 multiple installs of the app, as this serves no value beyond client 553 identification which is already provided by the client_id request 554 parameter. If an authorization server requires a client secret for 555 native apps, it MUST NOT assume that it is actually secret, unless 556 some method is being used to dynamically provision a unique secret to 557 each installation. 559 8. References 561 8.1. Normative References 563 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 564 RFC 6749, DOI 10.17487/RFC6749, October 2012, 565 . 567 [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key 568 for Code Exchange by OAuth Public Clients", RFC 7636, 569 DOI 10.17487/RFC7636, September 2015, 570 . 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, 574 DOI 10.17487/RFC2119, March 1997, 575 . 577 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 578 Resource Identifier (URI): Generic Syntax", STD 66, 579 RFC 3986, DOI 10.17487/RFC3986, January 2005, 580 . 582 8.2. Informative References 584 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 585 Threat Model and Security Considerations", RFC 6819, 586 DOI 10.17487/RFC6819, January 2013, 587 . 589 [iOS.URIScheme] 590 "Inter-App Communication", February 2015, . 595 [OSX.URIScheme] 596 "Launch Services Concepts", February 2015, . 601 [Android.URIScheme] 602 "Intents and Intent Filters", February 2015, 603 . 606 [WindowsPhone.URIScheme] 607 "Auto-launching apps using file and URI associations for 608 Windows Phone 8", February 2015, 609 . 612 [Windows.URIScheme] 613 "Registering an Application to a URI Scheme", February 614 2015, . 617 [IANA.URISchemes] 618 "Uniform Resource Identifier (URI) Schemes", February 619 2015, . 622 [ChromeCustomTab] 623 "Chrome Custom Tabs", July 2015, 624 . 627 [SFSafariViewController] 628 "SafariServices Changes", July 2015, . 632 [Android.AppLinks] 633 "App Links", July 2015, 634 . 637 Appendix A. Operating System Specific Implementation Details 639 Most of this document attempts to lay out best practices in an 640 generic manner, referencing technology available on most operating 641 systems. This non-normative section contains OS-specific 642 implementation details that are accurate at the time of authorship. 644 It is expected that this OS-specific information will change, but 645 that the overall principles described in this document for using 646 external user-agents will remain valid for longer. 648 A.1. iOS Implementation Details 650 From iOS 9, apps can invoke the system browser without the user 651 leaving the app through SFSafariViewController 652 [SFSafariViewController], which implements the browser-view pattern. 653 This class has all the properties of the system browser, and is 654 considered an 'external user-agent', even though it is presented 655 within the host app. Regardless of whether the system browser is 656 opened, or SFSafariViewController, the return of the token goes 657 through the same system. 659 A.2. Android Implementation Details 661 Chrome 45 introduced the concept of Chrome Custom Tab 662 [ChromeCustomTab], which follows the browser-view pattern and allows 663 authentication without the user leaving the app. 665 The return of the token can go through the custom URI scheme or 666 claimed HTTPS URI (including those registered with the App Link 667 [Android.AppLinks] system), or the navigation events can be observed 668 by the host app. It is RECOMMENDED that the custom URI, or claimed 669 HTTPS URI options be used for better portability, to allow the user 670 to open the authorization request in the Chrome app, and to prevent 671 accidental observation of intermediate tokens on URI parameters. 673 At the time of writing, Android does allow apps to claim HTTPs links 674 (App Links), but not in a way that is usable for OAuth, the native 675 app is only opened if the intent is fired from outside the browser. 677 Appendix B. Acknowledgements 679 The author would like to acknowledge the work of Marius Scurtescu, 680 and Ben Wiley Sittler whose design for using custom URI schemes in 681 native OAuth 2.0 clients formed the basis of Section 4.1. 683 The following individuals contributed ideas, feedback, and wording 684 that shaped and formed the final specification: 686 Naveen Agarwal, John Bradley, Brian Campbell, Adam Dawes, Hannes 687 Tschofenig, Ashish Jain, Paul Madsen, Breno de Medeiros, Eric Sachs, 688 Nat Sakimura, Steve Wright, Erik Wahlstrom, Andy Zmolek. 690 Authors' Addresses 692 William Denniss 693 Google 694 1600 Amphitheatre Pkwy 695 Mountain View, CA 94043 696 USA 698 Phone: +1 650-253-0000 699 Email: wdenniss@google.com 700 URI: http://google.com/ 702 John Bradley 703 Ping Identity 705 Phone: +1 202-630-5272 706 Email: ve7jtb@ve7jtb.com 707 URI: http://www.thread-safe.com/