idnits 2.17.1 draft-parecki-oauth-browser-based-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 08, 2018) is 1959 days in the past. Is this intentional? 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'CSP2' -- Possible downref: Non-RFC (?) normative reference: ref. 'Fetch' ** Downref: Normative reference to an Informational RFC: RFC 6819 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Authentication Protocol A. Parecki 3 Internet-Draft Okta 4 Intended status: Best Current Practice D. Waite 5 Expires: June 11, 2019 Ping Identity 6 December 08, 2018 8 OAuth 2.0 for Browser-Based Apps 9 draft-parecki-oauth-browser-based-apps-02 11 Abstract 13 OAuth 2.0 authorization requests from apps running entirely in a 14 browser are unable to use a Client Secret during the process, since 15 they have no way to keep a secret confidential. This specification 16 details the security considerations that must be taken into account 17 when developing browser-based applications, as well as best practices 18 for how they can securely implement OAuth 2.0. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 11, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 5. First-Party Applications . . . . . . . . . . . . . . . . . . 4 59 6. Architectural Considerations . . . . . . . . . . . . . . . . 5 60 6.1. Apps Served from the Same Domain as the API . . . . . . . 5 61 6.2. Browser-Based App with a Backend Component . . . . . . . 5 62 7. Authorization Code Flow . . . . . . . . . . . . . . . . . . . 6 63 7.1. Initiating the Authorization Request from a Browser-Based 64 Application . . . . . . . . . . . . . . . . . . . . . . . 6 65 7.2. Handling the Authorization Code Redirect . . . . . . . . 6 66 8. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . . . 7 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 9.1. Registration of Browser-Based Apps . . . . . . . . . . . 7 69 9.2. Client Authentication . . . . . . . . . . . . . . . . . . 7 70 9.3. Client Impersonation . . . . . . . . . . . . . . . . . . 8 71 9.4. Cross-Site Request Forgery Protections . . . . . . . . . 8 72 9.5. Authorization Server Mix-Up Mitigation . . . . . . . . . 8 73 9.6. Cross-Domain Requests . . . . . . . . . . . . . . . . . . 9 74 9.7. Content-Security Policy . . . . . . . . . . . . . . . . . 9 75 9.8. OAuth Implicit Grant Authorization Flow . . . . . . . . . 9 76 9.8.1. Threat: Interception of the Redirect URI . . . . . . 10 77 9.8.2. Threat: Access Token Leak in Browser History . . . . 10 78 9.8.3. Threat: Manipulation of Scripts . . . . . . . . . . . 10 79 9.8.4. Threat: Access Token Leak to Third Party Scripts . . 10 80 9.8.5. Countermeasures . . . . . . . . . . . . . . . . . . . 11 81 9.8.6. Disadvantages of the Implicit Flow . . . . . . . . . 11 82 9.8.7. Historic Note . . . . . . . . . . . . . . . . . . . . 12 83 9.9. Additional Security Considerations . . . . . . . . . . . 12 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 87 11.2. Informative References . . . . . . . . . . . . . . . . . 13 88 Appendix A. Server Support Checklist . . . . . . . . . . . . . . 13 89 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 This specification describes the current best practices for 95 implementing OAuth 2.0 authorization flows in applications running 96 entirely in a browser. 98 For native application developers using OAuth 2.0 and OpenID Connect, 99 an IETF BCP (best current practice) was published that guides 100 integration of these technologies. This document is formally known 101 as [RFC8252] or BCP 212, but nicknamed "AppAuth" after the OpenID 102 Foundation-sponsored set of libraries that assist developers in 103 adopting these practices. 105 AppAuth steers developers away from performing user authorization via 106 embedding user agents such as browser controls into native apps, 107 instead insisting that an external agent (such as the system browser) 108 be used. The RFC continues on to promote capabilities and 109 supplemental specifications beyond the base OAuth 2.0 and OpenID 110 Connect specifications to improve baseline security, such as 111 [RFC7636], also known as PKCE. 113 OAuth 2.0 for Browser-Based Apps addresses the similarities between 114 implementing OAuth for native apps as well as browser-based apps, and 115 includes additional considerations when running in a browser. This 116 is primarily focused on OAuth, except where OpenID Connect provides 117 additional considerations. 119 2. Notational Conventions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in 124 [RFC2119]. 126 3. Terminology 128 In addition to the terms defined in referenced specifications, this 129 document uses the following terms: 131 "OAuth": In this document, "OAuth" refers to OAuth 2.0, [RFC6749]. 133 "Browser-based application": An application that runs entirely in a 134 web browser, usually written in JavaScript, where the source code 135 is downloaded from a domain prior to execution. Also sometimes 136 referred to as a "single-page application", or "SPA". 138 4. Overview 140 For authorizing users within a browser-based application, the best 141 current practice is to 143 o Use the OAuth 2.0 authorization code flow with the PKCE extension 145 o Require the OAuth 2.0 state parameter 146 o Recommend exact matching of redirect URIs, and require the 147 hostname of the redirect URI match the hostname of the URL the app 148 was served from 150 o Do not return access tokens in the front channel 152 Previously it was recommended that browser-based applications use the 153 OAuth 2.0 Implicit flow. That approach has several drawbacks, 154 including the fact that access tokens are returned in the front- 155 channel via the fragment part of the redirect URI, and as such are 156 vulnerable to a variety of attacks where the access token can be 157 intercepted or stolen. See Section 9.8 for a deeper analysis of 158 these attacks and the drawbacks of using the Implicit flow in 159 browsers, many of which are described by [oauth-security-topics]. 161 Instead, browser-based apps can perform the OAuth 2.0 authorization 162 code flow and make a POST request to the token endpoint to exchange 163 an authorization code for an access token, just like other OAuth 164 clients. This ensures that access tokens are not sent via the less 165 secure front-channel, and are only returned over an HTTPS connection 166 initiated from the application. Combined with PKCE, this enables the 167 authorization server to ensure that authorization codes are useless 168 even if intercepted in transport. 170 5. First-Party Applications 172 While OAuth and OpenID Connect were initially created to allow third- 173 party applications to access an API on behalf of a user, they have 174 both proven to be useful in a first-party scenario as well. First- 175 party apps are applications created by the same organization that 176 provides the API being accessed by the application. 178 For example, a web email client provided by the operator of the email 179 account, or a mobile banking application created by bank itself. 180 (Note that there is no requirement that the application actually be 181 developed by the same company; a mobile banking application developed 182 by a contractor that is branded as the bank's application is still 183 considered a first-party application.) The first-party app 184 consideration is about the user's relationship to the application and 185 the service. 187 To conform to this best practice, first-party applications using 188 OAuth or OpenID Connect MUST use an OAuth Authorization Code flow as 189 described later in this document or use the OAuth Password grant. 191 It is strongly RECOMMENDED that applications use the Authorization 192 Code flow over the Password grant for several reasons. By 193 redirecting to the authorization server, this provides the 194 authorization server the opportunity to prompt the user for multi- 195 factor authentication options, take advantage of single-sign-on 196 sessions, or use third-party identity providers. In contrast, the 197 Password grant does not provide any built-in mechanism for these, and 198 must be extended with custom code. 200 6. Architectural Considerations 202 In some cases, it may make sense to avoid the use of a strictly 203 browser-based OAuth application entirely, instead using an 204 architecture that can provide better security. 206 6.1. Apps Served from the Same Domain as the API 208 For simple system architectures, such as when the JavaScript 209 application is served from the same domain as the API (resource 210 server) being accessed, it is likely a better decision to avoid using 211 OAuth entirely, and just use session authentication to communicate 212 with the API. 214 OAuth and OpenID Connect provide very little benefit in this 215 deployment scenario, so it is recommended to reconsider whether you 216 need OAuth or OpenID Connect at all in this case. Session 217 authentication has the benefit of having fewer moving parts and fewer 218 attack vectors. OAuth and OpenID Connect were created primarily for 219 third-party or federated access to APIs, so may not be the best 220 solution in a same-domain scenario. 222 6.2. Browser-Based App with a Backend Component 224 To avoid the risks inherent in handling OAuth access tokens from a 225 purely browser-based application, implementations may wish to move 226 the authorization code exchange and handling of access and refresh 227 tokens into a backend component. 229 The backend component essentially becomes a new authorization server 230 for the code running in the browser, issuing its own tokens (e.g. a 231 session cookie). Security of the connection between code running in 232 the browser and this backend component is assumed to utilize browser- 233 level protection mechanisms. Details are out of scope of this 234 document, but many recommendations can be found at the OWASP 235 Foundation (https://www.owasp.org/). 237 In this scenario, the backend component may be a confidential client 238 which is issued its own client secret. Despite this, there are still 239 some ways in which this application is effectively a public client, 240 as the end result is the application's code is still running in the 241 browser and visible to the user. Some authorization servers may have 242 different policies for public and confidential clients, and this type 243 of hybrid approach does not provide all the assurances of 244 confidential clients that an authorization server is expecting. 245 Authorization servers may wish to treat this type of deployment as a 246 public client. 248 7. Authorization Code Flow 250 Public browser-based apps needing user authorization create an 251 authorization request URI with the authorization code grant type per 252 Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of 253 being received by the app. 255 7.1. Initiating the Authorization Request from a Browser-Based 256 Application 258 Public browser-based apps MUST implement the Proof Key for Code 259 Exchange (PKCE [RFC7636]) extension to OAuth, and authorization 260 servers MUST support PKCE for such clients. 262 The PKCE extension prevents an attack where the authorization code is 263 intercepted and exchanged for an access token by a malicious client, 264 by providing the authorization server with a way to verify the same 265 client instance that exchanges the authorization code is the same one 266 that initiated the flow. 268 Browser-based apps MUST use the OAuth 2.0 "state" parameter to 269 protect themselves against Cross-Site Request Forgery and 270 authorization code swap attacks and MUST use a unique value for each 271 authorization request, and MUST verify the returned state in the 272 authorization response matches the original state the app created. 274 7.2. Handling the Authorization Code Redirect 276 Authorization servers SHOULD require an exact match of a registered 277 redirect URI. 279 If an authorization server wishes to provide some flexibility in 280 redirect URI usage to clients, it MAY require that only the hostname 281 component of the redirect URI match the hostname of the URL the 282 application is served from. 284 Authorization servers MUST support one of the two redirect URI 285 validation mechanisms as described above. 287 8. Refresh Tokens 289 Refresh tokens provide a way for applications to obtain a new access 290 token when the initial access token expires. [oauth-security-topics] 291 describes some additional requirements around refresh tokens on top 292 of the recommendations of [RFC6749]. 294 For public clients, the risk of a leaked refresh token is much 295 greater than leaked access tokens, since an attacker can potentially 296 continue using the stoken refresh token to obtain new access without 297 being detectable by the authorization server. Additionally, browser- 298 based applications provide many attack vectors by which a refresh 299 token can be leaked. As such, these applications are considered a 300 higher risk for handling refresh tokens. 302 Authorization servers SHOULD NOT issue refresh tokens to browser- 303 based applications. 305 If an authorization server does choose to issue refresh tokens to 306 browser-based applications, then it MUST issue a new refresh token 307 with every access token refresh response. Doing this mitigates the 308 risk of a leaked refresh token, as a leaked refresh token can be 309 detected if both the attacker and the legitimate client attempt to 310 use the same refresh token. Authorization servers MUST follow the 311 additional refresh token replay mitigation techniques described in 312 [oauth-security-topics]. 314 9. Security Considerations 316 9.1. Registration of Browser-Based Apps 318 Browser-based applications are considered public clients as defined 319 by section 2.1 of OAuth 2.0 [RFC6749], and MUST be registered with 320 the authorization server as such. Authorization servers MUST record 321 the client type in the client registration details in order to 322 identify and process requests accordingly. 324 Authorization servers MUST require that browser-based applications 325 register one or more redirect URIs. 327 9.2. Client Authentication 329 Since a browser-based application's source code is delivered to the 330 end-user's browser, it cannot contain provisioned secrets. As such, 331 a browser-based app with native OAuth support is considered a public 332 client as defined by Section 2.1 of OAuth 2.0 [RFC6749]. 334 Secrets that are statically included as part of an app distributed to 335 multiple users should not be treated as confidential secrets, as one 336 user may inspect their copy and learn the shared secret. For this 337 reason, and those stated in Section 5.3.1 of [RFC6819], it is NOT 338 RECOMMENDED for authorization servers to require client 339 authentication of browser-based applications using a shared secret, 340 as this serves little value beyond client identification which is 341 already provided by the client_id request parameter. 343 Authorization servers that still require a statically included shared 344 secret for SPA clients MUST treat the client as a public client, and 345 not accept the secret as proof of the client's identity. Without 346 additional measures, such clients are subject to client impersonation 347 (see Section 9.3 below). 349 9.3. Client Impersonation 351 As stated in Section 10.2 of OAuth 2.0 [RFC6749], the authorization 352 server SHOULD NOT process authorization requests automatically 353 without user consent or interaction, except when the identity of the 354 client can be assured. Even when the user has previously approved an 355 authorization request for a given client_id, the request SHOULD be 356 processed as if no previous request had been approved, unless the 357 identity of the client can be proven. 359 If authorization servers restrict redirect URIs to a fixed set of 360 absolute HTTPS URIs without wildcard domains, paths, or query string 361 components, this exact match of registered absolute HTTPS URIs MAY be 362 accepted by authorization servers as proof of identity of the client 363 for the purpose of deciding whether to automatically process an 364 authorization request when a previous request for the client_id has 365 already been approved. 367 9.4. Cross-Site Request Forgery Protections 369 Section 5.3.5 of [RFC6819] recommends using the "state" parameter to 370 link client requests and responses to prevent CSRF (Cross-Site 371 Request Forgery) attacks. To conform to this best practice, use of 372 the "state" parameter is REQUIRED, as described in Section 7.1. 374 9.5. Authorization Server Mix-Up Mitigation 376 The security considerations around the authorization server mix-up 377 that are referenced in Section 8.10 of [RFC8252] also apply to 378 browser-based apps. 380 Clients MUST use a unique redirect URI for each authorization server 381 used by the application. The client MUST store the redirect URI 382 along with the session data (e.g. along with "state") and MUST verify 383 that the URI on which the authorization response was received exactly 384 matches. 386 9.6. Cross-Domain Requests 388 To complete the authorization code flow, the browser-based 389 application will need to exchange the authorization code for an 390 access token at the token endpoint. If the authorization server 391 provides additional endpoints to the application, such as metadata 392 URLs, dynamic client registration, revocation, introspection, 393 discovery or user info endpoints, these endpoints may also be 394 accessed by the browser-based app. Since these requests will be made 395 from a browser, authorization servers MUST support the necessary CORS 396 headers (defined in [Fetch]) to allow the browser to make the 397 request. 399 This specification does not include guidelines for deciding whether a 400 CORS policy for the token endpoint should be a wildcard origin or 401 more restrictive. Note, however, that the browser will attempt to 402 GET or POST to the API endpoint before knowing any CORS policy; it 403 simply hides the succeeding or failing result from JavaScript if the 404 policy does not allow sharing. If POSTs in particular from 405 unsupported single-page applications are to be rejected as errors per 406 authorization server security policy, such rejection is typically 407 done based on the Origin request header. 409 9.7. Content-Security Policy 411 A browser-based application that wishes to use either long-lived 412 refresh tokens or privileged scopes SHOULD restrict its JavaScript 413 execution to a set of statically hosted scripts via a Content 414 Security Policy ([CSP2]) or similar mechanism. A strong Content 415 Security Policy can limit the potential attack vectors for malicious 416 JavaScript to be executed on the page. 418 9.8. OAuth Implicit Grant Authorization Flow 420 The OAuth 2.0 Implicit grant authorization flow (defined in 421 Section 4.2 of OAuth 2.0 [RFC6749]) works by receiving an access 422 token in the HTTP redirect (front-channel) immediately without the 423 code exchange step. In this case, the access token is returned in 424 the fragment part of the redirect URI, providing an attacker with 425 several opportunities to intercept and steal the access token. 426 Several attacks on the implicit flow are described by [RFC6819] and 427 [oauth-security-topics], not all of which have sufficient mitigation 428 strategies. 430 9.8.1. Threat: Interception of the Redirect URI 432 If an attacker is able to cause the authorization response to be sent 433 to a URI under his control, he will directly get access to the 434 fragment carrying the access token. A method of performing this 435 attack is described in detail in [oauth-security-topics]. 437 9.8.2. Threat: Access Token Leak in Browser History 439 An attacker could obtain the access token from the browser's history. 440 The countermeasures recommended by [RFC6819] are limited to using 441 short expiration times for tokens, and indicating that browsers 442 should not cache the response. Neither of these fully prevent this 443 attack, they only reduce the potential damage. 445 Additionally, many browsers now also sync browser history to cloud 446 services and to multiple devices, providing an even wider attack 447 surface to extract access tokens out of the URL. 449 9.8.3. Threat: Manipulation of Scripts 451 An attacker could modify the page or inject scripts into the browser 452 via various means, including when the browser's HTTPS connection is 453 being man-in-the-middled by for example a corporate network. While 454 this type of attack is typically out of scope of basic security 455 recommendations to prevent, in the case of browser-based apps it is 456 much easier to perform this kind of attack, where an injected script 457 can suddenly have access to everything on the page. 459 The risk of a malicious script running on the page is far greater 460 when the application uses a known standard way of obtaining access 461 tokens, namely that the attacker can always look at the 462 window.location to find an access token. This threat profile is very 463 different compared to an attacker specifically targeting an 464 individual application by knowing where or how an access token 465 obtained via the authorization code flow may end up being stored. 467 9.8.4. Threat: Access Token Leak to Third Party Scripts 469 It is relatively common to use third-party scripts in browser-based 470 apps, such as analytics tools, crash reporting, and even things like 471 a Facebook or Twitter "like" button. In these situations, the author 472 of the application may not be able to be fully aware of the entirety 473 of the code running in the application. When an access token is 474 returned in the fragment, it is visible to any third-party scripts on 475 the page. 477 9.8.5. Countermeasures 479 In addition to the countermeasures described by [RFC6819] and 480 [oauth-security-topics], using the authorization code with PKCE 481 avoids these attacks. 483 When PKCE is used, if an authorization code is stolen in transport, 484 the attacker is unable to do anything with the authorization code. 486 9.8.6. Disadvantages of the Implicit Flow 488 There are several additional reasons the Implicit flow is 489 disadvantageous compared to using the standard Authorization Code 490 flow. 492 o OAuth 2.0 provides no mechanism for a client to verify that an 493 access token was issued to it, which could lead to misuse and 494 possible impersonation attacks if a malicious party hands off an 495 access token it retrieved through some other means to the client. 497 o Returning an access token in the front channel redirect gives the 498 authorization server little assurance that the access token will 499 actually end up at the application, since there are many ways this 500 redirect may fail or be intercepted. 502 o Supporting the implicit flow requires additional code, more upkeep 503 and understanding of the related security considerations, while 504 limiting the authorization server to just the authorization code 505 flow reduces the attack surface of the implementation. 507 o If the JavaScript application gets wrapped into a native app, then 508 [RFC8252] also requires the use of the authorization code flow 509 with PKCE anyway. 511 In OpenID Connect, the id_token is sent in a known format (as a JWT), 512 and digitally signed. Performing OpenID Connect using the 513 authorization code flow also provides the additional benefit of the 514 client not needing to verify the JWT signature, as the token will 515 have been fetched over an HTTPS connection directly from the 516 authorization server. However, returning an id_token using the 517 Implicit flow requires the client validate the JWT signature, as 518 malicious parties could otherwise craft and supply fraudulent 519 id_tokens. 521 9.8.7. Historic Note 523 Historically, the Implicit flow provided an advantage to single-page 524 apps since JavaScript could always arbitrarily read and manipulate 525 the fragment portion of the URL without triggering a page reload. 526 Now with the Session History API (described in "Session history and 527 navigation" of [HTML]), browsers have a mechanism to modify the path 528 component of the URL without triggering a page reload, so this 529 overloaded use of the fragment portion is no longer needed. 531 9.9. Additional Security Considerations 533 The OWASP Foundation (https://www.owasp.org/) maintains a set of 534 security recommendations and best practices for web applications, and 535 it is RECOMMENDED to follow these best practices when creating an 536 OAuth 2.0 Browser-Based application. 538 10. IANA Considerations 540 This document does not require any IANA actions. 542 11. References 544 11.1. Normative References 546 [CSP2] West, M., Barth, A., and D. Veditz, "Content Security 547 Policy", December 2016. 549 [Fetch] whatwg, "Fetch", 2018. 551 [oauth-security-topics] 552 Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, 553 "OAuth 2.0 Security Best Current Practice", November 2018. 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, 557 DOI 10.17487/RFC2119, March 1997, 558 . 560 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 561 RFC 6749, DOI 10.17487/RFC6749, October 2012, 562 . 564 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 565 Threat Model and Security Considerations", RFC 6819, 566 DOI 10.17487/RFC6819, January 2013, 567 . 569 [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key 570 for Code Exchange by OAuth Public Clients", RFC 7636, 571 DOI 10.17487/RFC7636, September 2015, 572 . 574 [RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", 575 BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, 576 . 578 11.2. Informative References 580 [HTML] whatwg, "HTML", 2018. 582 Appendix A. Server Support Checklist 584 OAuth servers that support browser-based apps MUST: 586 1. Require "https" scheme redirect URIs. 588 2. Require exact matching on redirect URIs or matching the hostname 589 the application is served from. 591 3. Support PKCE [RFC7636]. Required to protect authorization code 592 grants sent to public clients. See Section 7.1 594 4. Support cross-domain requests at the token endpoint in order to 595 allow browsers to make the authorization code exchange request. 596 See Section 9.6 598 5. Not assume that browser-based clients can keep a secret, and 599 SHOULD NOT issue secrets to applications of this type. 601 Appendix B. Acknowledgements 603 The authors would like to acknowledge the work of William Denniss and 604 John Bradley, whose recommendation for native apps informed many of 605 the best practices for browser-based applications. The authors would 606 also like to thank Hannes Tschofenig and Torsten Lodderstedt, as well 607 as all the attendees of the Internet Identity Workshop 27 session at 608 which this BCP was originally proposed. 610 The following individuals contributed ideas, feedback, and wording 611 that shaped and formed the final specification: 613 Annabelle Backman, Brian Campbell, Brock Allen, Christian Mainka, 614 Daniel Fett, George Fletcher, Hannes Tschofenig, John Bradley, Joseph 615 Heenan, Justin Richer, Karl McGuinness, Tomek Stojecki, Torsten 616 Lodderstedt, and Vittorio Bertocci. 618 Authors' Addresses 620 Aaron Parecki 621 Okta 623 Email: aaron@parecki.com 624 URI: https://aaronparecki.com 626 David Waite 627 Ping Identity 629 Email: david@alkaline-solutions.com