draft-ietf-oauth-browser-based-apps-02.txt   draft-ietf-oauth-browser-based-apps-03.txt 
Open Authentication Protocol A. Parecki Open Authentication Protocol A. Parecki
Internet-Draft Okta Internet-Draft Okta
Intended status: Best Current Practice D. Waite Intended status: Best Current Practice D. Waite
Expires: January 9, 2020 Ping Identity Expires: January 25, 2020 Ping Identity
July 08, 2019 July 24, 2019
OAuth 2.0 for Browser-Based Apps OAuth 2.0 for Browser-Based Apps
draft-ietf-oauth-browser-based-apps-02 draft-ietf-oauth-browser-based-apps-03
Abstract Abstract
OAuth 2.0 authorization requests from browser-based apps must be made
using the authorization code grant with the PKCE extension, and
should not be issued a client secret when registered.
This specification details the security considerations that must be This specification details the security considerations that must be
taken into account when developing browser-based applications, as taken into account when developing browser-based applications, as
well as best practices for how they can securely implement OAuth 2.0. well as best practices for how they can securely implement OAuth 2.0.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 January 9, 2020. This Internet-Draft will expire on January 25, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. First-Party Applications . . . . . . . . . . . . . . . . . . 5 5. First-Party Applications . . . . . . . . . . . . . . . . . . 4
6. Application Architecture Patterns . . . . . . . . . . . . . . 5 6. Application Architecture Patterns . . . . . . . . . . . . . . 5
6.1. Apps Served from a Common Domain as the Resource Server . 6 6.1. Apps Served from a Common Domain as the Resource Server . 5
6.2. Apps Served from a Dynamic Application Server . . . . . . 6 6.2. JavaScript Applications with a Backend . . . . . . . . . 6
6.3. Apps Served from a Static Web Server . . . . . . . . . . 8 6.3. JavaScript Applications without a Backend . . . . . . . . 8
7. Authorization Code Flow . . . . . . . . . . . . . . . . . . . 9 7. Authorization Code Flow . . . . . . . . . . . . . . . . . . . 9
7.1. Initiating the Authorization Request from a Browser-Based 7.1. Initiating the Authorization Request from a Browser-Based
Application . . . . . . . . . . . . . . . . . . . . . . . 9 Application . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Handling the Authorization Code Redirect . . . . . . . . 9 7.2. Handling the Authorization Code Redirect . . . . . . . . 9
8. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . . . 10 8. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9.1. Registration of Browser-Based Apps . . . . . . . . . . . 10 9.1. Registration of Browser-Based Apps . . . . . . . . . . . 10
9.2. Client Authentication . . . . . . . . . . . . . . . . . . 10 9.2. Client Authentication . . . . . . . . . . . . . . . . . . 10
9.3. Client Impersonation . . . . . . . . . . . . . . . . . . 11 9.3. Client Impersonation . . . . . . . . . . . . . . . . . . 11
9.4. Cross-Site Request Forgery Protections . . . . . . . . . 11 9.4. Cross-Site Request Forgery Protections . . . . . . . . . 11
skipping to change at page 2, line 47 skipping to change at page 2, line 44
9.8.5. Countermeasures . . . . . . . . . . . . . . . . . . . 14 9.8.5. Countermeasures . . . . . . . . . . . . . . . . . . . 14
9.8.6. Disadvantages of the Implicit Flow . . . . . . . . . 14 9.8.6. Disadvantages of the Implicit Flow . . . . . . . . . 14
9.8.7. Historic Note . . . . . . . . . . . . . . . . . . . . 15 9.8.7. Historic Note . . . . . . . . . . . . . . . . . . . . 15
9.9. Additional Security Considerations . . . . . . . . . . . 15 9.9. Additional Security Considerations . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Server Support Checklist . . . . . . . . . . . . . . 16 Appendix A. Server Support Checklist . . . . . . . . . . . . . . 16
Appendix B. Document History . . . . . . . . . . . . . . . . . . 16 Appendix B. Document History . . . . . . . . . . . . . . . . . . 16
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 17 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This specification describes the current best practices for This specification describes the current best practices for
implementing OAuth 2.0 authorization flows in applications running implementing OAuth 2.0 authorization flows in applications running
entirely in a browser. entirely in a browser.
For native application developers using OAuth 2.0 and OpenID Connect, For native application developers using OAuth 2.0 and OpenID Connect,
an IETF BCP (best current practice) was published that guides an IETF BCP (best current practice) was published that guides
integration of these technologies. This document is formally known integration of these technologies. This document is formally known
as [RFC8252] or BCP 212, but nicknamed "AppAuth" after the OpenID as [RFC8252] or BCP 212, but nicknamed "AppAuth" after the OpenID
Foundation-sponsored set of libraries that assist developers in Foundation-sponsored set of libraries that assist developers in
adopting these practices. adopting these practices.
AppAuth steers developers away from performing user authorization via [RFC8252] makes specific recommendations for how to securely
embedding user agents such as browser controls into native apps, implement OAuth in native applications, including incorporating
instead insisting that an external agent (such as the system browser) additional OAuth extensions where needed.
be used. The RFC continues on to promote capabilities and
supplemental specifications beyond the base OAuth 2.0 and OpenID
Connect specifications to improve baseline security, such as
[RFC7636], also known as PKCE.
OAuth 2.0 for Browser-Based Apps addresses the similarities between OAuth 2.0 for Browser-Based Apps addresses the similarities between
implementing OAuth for native apps as well as browser-based apps, and implementing OAuth for native apps as well as browser-based apps, and
includes additional considerations when running in a browser. This includes additional considerations when running in a browser. This
is primarily focused on OAuth, except where OpenID Connect provides is primarily focused on OAuth, except where OpenID Connect provides
additional considerations. additional considerations.
2. Notational Conventions 2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 47 skipping to change at page 4, line 35
Applications should: Applications should:
o Use the OAuth 2.0 authorization code flow with the PKCE extension o Use the OAuth 2.0 authorization code flow with the PKCE extension
o Use the OAuth 2.0 state parameter to carry one-time use CSRF o Use the OAuth 2.0 state parameter to carry one-time use CSRF
tokens tokens
o Register one or more redirect URIs, and not vary the redirect URI o Register one or more redirect URIs, and not vary the redirect URI
per authorization request per authorization request
OAuth 2.0 servers should: OAuth 2.0 servers must:
o Require exact matching of registered redirect URIs o Require exact matching of registered redirect URIs
5. First-Party Applications 5. First-Party Applications
While OAuth and OpenID Connect were initially created to allow third- While OAuth was initially created to allow third-party applications
party applications to access an API on behalf of a user, they have to access an API on behalf of a user, it has proven to be useful in a
both proven to be useful in a first-party scenario as well. First- first-party scenario as well. First-party apps are applications
party apps are applications where by the same organization that where the same organization provides both the API and the
provides the API being accessed by the application. application.
For example, a web email client provided by the operator of the email For example, a web email client provided by the operator of the email
account, or a mobile banking application created by bank itself. account, or a mobile banking application created by bank itself.
(Note that there is no requirement that the application actually be (Note that there is no requirement that the application actually be
developed by the same company; a mobile banking application developed developed by the same company; a mobile banking application developed
by a contractor that is branded as the bank's application is still by a contractor that is branded as the bank's application is still
considered a first-party application.) The first-party app considered a first-party application.) The first-party app
consideration is about the user's relationship to the application and consideration is about the user's relationship to the application and
the service. the service.
skipping to change at page 5, line 40 skipping to change at page 5, line 25
factor authentication options, take advantage of single-sign-on factor authentication options, take advantage of single-sign-on
sessions, or use third-party identity providers. In contrast, the sessions, or use third-party identity providers. In contrast, the
Password grant does not provide any built-in mechanism for these, and Password grant does not provide any built-in mechanism for these, and
must be extended with custom code. must be extended with custom code.
6. Application Architecture Patterns 6. Application Architecture Patterns
There are three primary architectural patterns available when There are three primary architectural patterns available when
building browser-based applications. building browser-based applications.
o JavaScript served from a common domain as the resource server o a JavaScript application served from a common domain as the
resource server
o JavaScript served from a dynamic application server o a JavaScript application with a backend
o JavaScript served from a static web server o a JavaScript application with no backend, accessing resource
servers directly
These three architectures have different use cases and These three architectures have different use cases and
considerations. considerations.
6.1. Apps Served from a Common Domain as the Resource Server 6.1. Apps Served from a Common Domain as the Resource Server
For simple system architectures, such as when the JavaScript For simple system architectures, such as when the JavaScript
application is served from a domain that can share cookies with the application is served from a domain that can share cookies with the
domain of the API (resource server), it is likely a better decision domain of the API (resource server), OAuth adds additional attack
to avoid using OAuth entirely, and just use session authentication to vectors that could be avoided with a different solution.
communicate directly with the API.
OAuth and OpenID Connect provide very little benefit in this In particular, using any redirect-based mechanism of obtaining an
deployment scenario, so it is recommended to reconsider whether you access token enables the redirect-based attacks described in
need OAuth or OpenID Connect at all in this case. Session [oauth-security-topics], but if the application, AS and API share a
authentication has the benefit of having fewer moving parts and fewer domain, then it is unnecessary to use a redirect mechanism to
attack vectors. OAuth and OpenID Connect were created primarily for communicate between them.
third-party or federated access to APIs, so may not be the best
solution in a same-domain scenario.
6.2. Apps Served from a Dynamic Application Server An additional concern with handling access tokens in a browser is
that there is no secure storage mechanism where JavaScript code can
keep the access token to be later used in an API request. Using an
OAuth flow results in the JavaScript code getting an access token,
needing to store it somewhere, and then retrieve it to make an API
request. Instead, it is more secure to use an HTTP-only cookie
between the JavaScript application and API so that the JavaScript
code can't access the cookie value itself.
In this situation, it is best to avoid letting the JavaScript code
ever see the access token, and instead use a mechanism such as the
"JavaScript Applications with a Backend" pattern described below, to
keep access tokens out of the browser.
If your JavaScript application has no backend, but still shares a
domain with the resource server, then it may be best to avoid using
OAuth entirely.
OAuth was created primarily for third-party or federated access to
APIs, so it may not be the best solution in a same-domain scenario.
6.2. JavaScript Applications with a Backend
+-------------+ +-------------+
| | | |
|Authorization| |Authorization|
| Server | | Server |
| | | |
+-------------+ +-------------+
^ + ^ +
|(A) |(B) |(A) |(B)
| | | |
skipping to change at page 7, line 46 skipping to change at page 7, line 46
In this architecture, the JavaScript code is loaded from a dynamic In this architecture, the JavaScript code is loaded from a dynamic
Application Server that also has the ability to execute code itself. Application Server that also has the ability to execute code itself.
This enables the ability to keep all of the steps involved in This enables the ability to keep all of the steps involved in
obtaining an access token outside of the JavaScript application. obtaining an access token outside of the JavaScript application.
(Common examples of this architecture are an Angular front-end with a (Common examples of this architecture are an Angular front-end with a
.NET backend, or a React front-end with a Spring Boot backend.) .NET backend, or a React front-end with a Spring Boot backend.)
The Application Server SHOULD be considered a confidential client, The Application Server SHOULD be considered a confidential client,
and issued its own client secret. The Application Server SHOULD use and issued its own client secret. The Application Server SHOULD use
the OAuth 2.0 authorization code grant to initiate a request request the OAuth 2.0 authorization code grant to initiate a request for an
for an access token. Upon handling the redirect from the access token. Upon handling the redirect from the Authorization
Authorization Server, the Application Server will request an access Server, the Application Server will request an access token using the
token using the authorization code returned (A), which will be authorization code returned (A), which will be returned to the
returned to the Application Server (B). The Application Server Application Server (B). The Application Server utilizes its own
utilizes its own session with the browser to store the access token. session with the browser to store the access token.
When the JavaScript application in the browser wants to make a When the JavaScript application in the browser wants to make a
request to the Resource Server, it MUST instead make the request to request to the Resource Server, it MUST instead make the request to
the Application Server, and the Application Server will make the the Application Server, and the Application Server will make the
request with the access token to the Resource Server (C), and forward request with the access token to the Resource Server (C), and forward
the response (D) back to the browser. the response (D) back to the browser.
Security of the connection between code running in the browser and Security of the connection between code running in the browser and
this Application Server is assumed to utilize browser-level this Application Server is assumed to utilize browser-level
protection mechanisms. Details are out of scope of this document, protection mechanisms. Details are out of scope of this document,
skipping to change at page 8, line 27 skipping to change at page 8, line 27
Application Server. Application Server.
In this scenario, the session between the browser and Application In this scenario, the session between the browser and Application
Server MAY be either a session cookie provided by the Application Server MAY be either a session cookie provided by the Application
Server, OR the access token itself. Note that if the access token is Server, OR the access token itself. Note that if the access token is
used as the session identifier, this exposes the access token to the used as the session identifier, this exposes the access token to the
end user even if it is not available to the JavaScript application, end user even if it is not available to the JavaScript application,
so some authorization servers may wish to limit the capabilities of so some authorization servers may wish to limit the capabilities of
these clients to mitigate risk. these clients to mitigate risk.
6.3. Apps Served from a Static Web Server 6.3. JavaScript Applications without a Backend
+---------------+ +--------------+ +---------------+ +--------------+
| | | | | | | |
| Authorization | | Resource | | Authorization | | Resource |
| Server | | Server | | Server | | Server |
| | | | | | | |
+---------------+ +--------------+ +---------------+ +--------------+
^ + ^ + ^ + ^ +
| | | | | | | |
skipping to change at page 9, line 22 skipping to change at page 9, line 22
request to the Resource Server, it can include the access token in request to the Resource Server, it can include the access token in
the request (D) and make the request directly. the request (D) and make the request directly.
In this scenario, the Authorization Server and Resource Server MUST In this scenario, the Authorization Server and Resource Server MUST
support the necessary CORS headers to enable the JavaScript code to support the necessary CORS headers to enable the JavaScript code to
make this POST request from the domain on which the script is make this POST request from the domain on which the script is
executing. (See Section 9.6 for additional details.) executing. (See Section 9.6 for additional details.)
7. Authorization Code Flow 7. Authorization Code Flow
Public browser-based apps needing user authorization create an Public browser-based apps that use the authorization code grant type
authorization request URI with the authorization code grant type per described in Section 4.1 of OAuth 2.0 [RFC6749] MUST also follow
Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of these additional requirements described in this section.
being received by the app.
7.1. Initiating the Authorization Request from a Browser-Based 7.1. Initiating the Authorization Request from a Browser-Based
Application Application
Public browser-based apps MUST implement the Proof Key for Code Public browser-based apps MUST implement the Proof Key for Code
Exchange (PKCE [RFC7636]) extension to OAuth, and authorization Exchange (PKCE [RFC7636]) extension to OAuth, and authorization
servers MUST support PKCE for such clients. servers MUST support PKCE for such clients.
The PKCE extension prevents an attack where the authorization code is The PKCE extension prevents an attack where the authorization code is
intercepted and exchanged for an access token by a malicious client, intercepted and exchanged for an access token by a malicious client,
skipping to change at page 10, line 14 skipping to change at page 10, line 14
8. Refresh Tokens 8. Refresh Tokens
Refresh tokens provide a way for applications to obtain a new access Refresh tokens provide a way for applications to obtain a new access
token when the initial access token expires. [oauth-security-topics] token when the initial access token expires. [oauth-security-topics]
describes some additional requirements around refresh tokens on top describes some additional requirements around refresh tokens on top
of the recommendations of [RFC6749]. of the recommendations of [RFC6749].
For public clients, the risk of a leaked refresh token is much For public clients, the risk of a leaked refresh token is much
greater than leaked access tokens, since an attacker can potentially greater than leaked access tokens, since an attacker can potentially
continue using the stoken refresh token to obtain new access without continue using the stolen refresh token to obtain new access tokens
being detectable by the authorization server. Additionally, browser- without being detectable by the authorization server. Additionally,
based applications provide many attack vectors by which a refresh browser-based applications provide many attack vectors by which a
token can be leaked. As such, these applications are considered a refresh token can be leaked. As such, these applications are
higher risk for handling refresh tokens. considered a higher risk for handling refresh tokens.
Authorization servers SHOULD NOT issue refresh tokens to browser- Authorization servers SHOULD NOT issue refresh tokens to browser-
based applications. based applications.
If an authorization server does choose to issue refresh tokens to If an authorization server does choose to issue refresh tokens to
browser-based applications, then it MUST issue a new refresh token browser-based applications, then it MUST issue a new refresh token
with every access token refresh response. Doing this mitigates the with every access token refresh response. Doing this mitigates the
risk of a leaked refresh token, as a leaked refresh token can be risk of a leaked refresh token, as a leaked refresh token can be
detected if both the attacker and the legitimate client attempt to detected if both the attacker and the legitimate client attempt to
use the same refresh token. Authorization servers MUST follow the use the same refresh token. Authorization servers MUST follow the
skipping to change at page 12, line 26 skipping to change at page 12, line 26
accessed by the browser-based app. Since these requests will be made accessed by the browser-based app. Since these requests will be made
from a browser, authorization servers MUST support the necessary CORS from a browser, authorization servers MUST support the necessary CORS
headers (defined in [Fetch]) to allow the browser to make the headers (defined in [Fetch]) to allow the browser to make the
request. request.
This specification does not include guidelines for deciding whether a This specification does not include guidelines for deciding whether a
CORS policy for the token endpoint should be a wildcard origin or CORS policy for the token endpoint should be a wildcard origin or
more restrictive. Note, however, that the browser will attempt to more restrictive. Note, however, that the browser will attempt to
GET or POST to the API endpoint before knowing any CORS policy; it GET or POST to the API endpoint before knowing any CORS policy; it
simply hides the succeeding or failing result from JavaScript if the simply hides the succeeding or failing result from JavaScript if the
policy does not allow sharing. If POSTs in particular from policy does not allow sharing.
unsupported single-page applications are to be rejected as errors per
authorization server security policy, such rejection is typically
done based on the Origin request header.
9.7. Content-Security Policy 9.7. Content-Security Policy
A browser-based application that wishes to use either long-lived A browser-based application that wishes to use either long-lived
refresh tokens or privileged scopes SHOULD restrict its JavaScript refresh tokens or privileged scopes SHOULD restrict its JavaScript
execution to a set of statically hosted scripts via a Content execution to a set of statically hosted scripts via a Content
Security Policy ([CSP2]) or similar mechanism. A strong Content Security Policy ([CSP2]) or similar mechanism. A strong Content
Security Policy can limit the potential attack vectors for malicious Security Policy can limit the potential attack vectors for malicious
JavaScript to be executed on the page. JavaScript to be executed on the page.
skipping to change at page 13, line 24 skipping to change at page 13, line 24
An attacker could obtain the access token from the browser's history. An attacker could obtain the access token from the browser's history.
The countermeasures recommended by [RFC6819] are limited to using The countermeasures recommended by [RFC6819] are limited to using
short expiration times for tokens, and indicating that browsers short expiration times for tokens, and indicating that browsers
should not cache the response. Neither of these fully prevent this should not cache the response. Neither of these fully prevent this
attack, they only reduce the potential damage. attack, they only reduce the potential damage.
Additionally, many browsers now also sync browser history to cloud Additionally, many browsers now also sync browser history to cloud
services and to multiple devices, providing an even wider attack services and to multiple devices, providing an even wider attack
surface to extract access tokens out of the URL. surface to extract access tokens out of the URL.
This is discussed in more detail in Section 4.3.2 of
[oauth-security-topics].
9.8.3. Threat: Manipulation of Scripts 9.8.3. Threat: Manipulation of Scripts
An attacker could modify the page or inject scripts into the browser An attacker could modify the page or inject scripts into the browser
via various means, including when the browser's HTTPS connection is via various means, including when the browser's HTTPS connection is
being man-in-the-middled by for example a corporate network. While being man-in-the-middled by for example a corporate network. While
this type of attack is typically out of scope of basic security this type of attack is typically out of scope of basic security
recommendations to prevent, in the case of browser-based apps it is recommendations to prevent, in the case of browser-based apps it is
much easier to perform this kind of attack, where an injected script much easier to perform this kind of attack, where an injected script
can suddenly have access to everything on the page. can suddenly have access to everything on the page.
skipping to change at page 15, line 10 skipping to change at page 15, line 10
authorization server. However, returning an id_token using the authorization server. However, returning an id_token using the
Implicit flow requires the client validate the JWT signature, as Implicit flow requires the client validate the JWT signature, as
malicious parties could otherwise craft and supply fraudulent malicious parties could otherwise craft and supply fraudulent
id_tokens. id_tokens.
9.8.7. Historic Note 9.8.7. Historic Note
Historically, the Implicit flow provided an advantage to single-page Historically, the Implicit flow provided an advantage to single-page
apps since JavaScript could always arbitrarily read and manipulate apps since JavaScript could always arbitrarily read and manipulate
the fragment portion of the URL without triggering a page reload. the fragment portion of the URL without triggering a page reload.
Now with the Session History API (described in "Session history and This was necessary in order to remove the access token from the URL
navigation" of [HTML]), browsers have a mechanism to modify the path after it was obtained by the app.
component of the URL without triggering a page reload, so this
overloaded use of the fragment portion is no longer needed. Modern browsers now have the Session History API (described in
"Session history and navigation" of [HTML]), which provides a
mechanism to modify the path and query string component of the URL
without triggering a page reload. This means modern browser-based
apps can use the unmodified OAuth 2.0 authorization code flow, since
they have the ability to remove the authorization code from the query
string without triggering a page reload thanks to the Session History
API.
9.9. Additional Security Considerations 9.9. Additional Security Considerations
The OWASP Foundation (https://www.owasp.org/) maintains a set of The OWASP Foundation (https://www.owasp.org/) maintains a set of
security recommendations and best practices for web applications, and security recommendations and best practices for web applications, and
it is RECOMMENDED to follow these best practices when creating an it is RECOMMENDED to follow these best practices when creating an
OAuth 2.0 Browser-Based application. OAuth 2.0 Browser-Based application.
10. IANA Considerations 10. IANA Considerations
skipping to change at page 15, line 37 skipping to change at page 15, line 44
11.1. Normative References 11.1. Normative References
[CSP2] West, M., Barth, A., and D. Veditz, "Content Security [CSP2] West, M., Barth, A., and D. Veditz, "Content Security
Policy", December 2016. Policy", December 2016.
[Fetch] whatwg, "Fetch", 2018. [Fetch] whatwg, "Fetch", 2018.
[oauth-security-topics] [oauth-security-topics]
Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
"OAuth 2.0 Security Best Current Practice", November 2018. "OAuth 2.0 Security Best Current Practice", July 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
skipping to change at page 16, line 40 skipping to change at page 16, line 49
allow browsers to make the authorization code exchange request. allow browsers to make the authorization code exchange request.
See Section 9.6 See Section 9.6
5. Not assume that browser-based clients can keep a secret, and 5. Not assume that browser-based clients can keep a secret, and
SHOULD NOT issue secrets to applications of this type. SHOULD NOT issue secrets to applications of this type.
Appendix B. Document History Appendix B. Document History
[[ To be removed from the final specification ]] [[ To be removed from the final specification ]]
-03
o Updated the historic note about the fragment URL clarifying that
the Session History API means browsers can use the unmodified
authorization code flow
o Rephrased "Authorization Code Flow" intro paragraph to better lead
into the next two sections
o Softened "is likely a better decision to avoid using OAuth
entirely" to "it may be..." for common-domain deployments
o Updated abstract to not be limited to public clients, since the
later sections talk about confidential clients
o Removed references to avoiding OpenID Connect for same-domain
architectures
o Updated headers to better describe architectures (Apps Served from
a Static Web Server -> JavaScript Applications without a Backend)
o Expanded "same-domain architecture" section to better explain the
problems that OAuth has in this scenario
o Referenced Security BCP in implicit flow attacks where possible
o Minor typo corrections
-02 -02
o Rewrote overview section incorporating feedback from Leo Tohill o Rewrote overview section incorporating feedback from Leo Tohill
o Updated summary recommendation bullet points to split out o Updated summary recommendation bullet points to split out
application and server requirements application and server requirements
o Removed the allowance on hostname-only redirect URI matching, now o Removed the allowance on hostname-only redirect URI matching, now
requiring exact redirect URI matching requiring exact redirect URI matching
skipping to change at page 17, line 39 skipping to change at page 18, line 29
The authors would like to acknowledge the work of William Denniss and The authors would like to acknowledge the work of William Denniss and
John Bradley, whose recommendation for native apps informed many of John Bradley, whose recommendation for native apps informed many of
the best practices for browser-based applications. The authors would the best practices for browser-based applications. The authors would
also like to thank Hannes Tschofenig and Torsten Lodderstedt, the also like to thank Hannes Tschofenig and Torsten Lodderstedt, the
attendees of the Internet Identity Workshop 27 session at which this attendees of the Internet Identity Workshop 27 session at which this
BCP was originally proposed, and the following individuals who BCP was originally proposed, and the following individuals who
contributed ideas, feedback, and wording that shaped and formed the contributed ideas, feedback, and wording that shaped and formed the
final specification: final specification:
Annabelle Backman, Brian Campbell, Brock Allen, Christian Mainka, Annabelle Backman, Brian Campbell, Brock Allen, Christian Mainka,
Daniel Fett, George Fletcher, Hannes Tschofenig, John Bradley, Joseph Daniel Fett, George Fletcher, Hannes Tschofenig, Janak Amarasena,
Heenan, Justin Richer, Karl McGuinness, Leo Tohill, Tomek Stojecki, John Bradley, Joseph Heenan, Justin Richer, Karl McGuinness, Leo
Torsten Lodderstedt, and Vittorio Bertocci. Tohill, Tomek Stojecki, Torsten Lodderstedt, and Vittorio Bertocci.
Authors' Addresses Authors' Addresses
Aaron Parecki Aaron Parecki
Okta Okta
Email: aaron@parecki.com Email: aaron@parecki.com
URI: https://aaronparecki.com URI: https://aaronparecki.com
David Waite David Waite
Ping Identity Ping Identity
Email: david@alkaline-solutions.com Email: david@alkaline-solutions.com
 End of changes. 28 change blocks. 
71 lines changed or deleted 117 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/