< draft-ietf-oauth-browser-based-apps-01.txt   draft-ietf-oauth-browser-based-apps-02.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: September 28, 2019 Ping Identity Expires: January 9, 2020 Ping Identity
March 27, 2019 July 08, 2019
OAuth 2.0 for Browser-Based Apps OAuth 2.0 for Browser-Based Apps
draft-ietf-oauth-browser-based-apps-01 draft-ietf-oauth-browser-based-apps-02
Abstract Abstract
OAuth 2.0 authorization requests from browser-based apps must be made OAuth 2.0 authorization requests from browser-based apps must be made
using the authorization code grant with the PKCE extension, and using the authorization code grant with the PKCE extension, and
should not be issued a client secret when registered. 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.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 September 28, 2019. This Internet-Draft will expire on January 9, 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. First-Party Applications . . . . . . . . . . . . . . . . . . 5 5. First-Party Applications . . . . . . . . . . . . . . . . . . 5
6. Architectural Considerations . . . . . . . . . . . . . . . . 5 6. Application Architecture Patterns . . . . . . . . . . . . . . 5
6.1. Apps Served from a Common Domain as the API . . . . . . . 5 6.1. Apps Served from a Common Domain as the Resource Server . 6
6.2. Browser-Based App with a Backend Component . . . . . . . 6 6.2. Apps Served from a Dynamic Application Server . . . . . . 6
7. Authorization Code Flow . . . . . . . . . . . . . . . . . . . 6 6.3. Apps Served from a Static Web Server . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . . . 6 Application . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Handling the Authorization Code Redirect . . . . . . . . 7 7.2. Handling the Authorization Code Redirect . . . . . . . . 9
8. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . . . 7 8. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9.1. Registration of Browser-Based Apps . . . . . . . . . . . 8 9.1. Registration of Browser-Based Apps . . . . . . . . . . . 10
9.2. Client Authentication . . . . . . . . . . . . . . . . . . 8 9.2. Client Authentication . . . . . . . . . . . . . . . . . . 10
9.3. Client Impersonation . . . . . . . . . . . . . . . . . . 8 9.3. Client Impersonation . . . . . . . . . . . . . . . . . . 11
9.4. Cross-Site Request Forgery Protections . . . . . . . . . 9 9.4. Cross-Site Request Forgery Protections . . . . . . . . . 11
9.5. Authorization Server Mix-Up Mitigation . . . . . . . . . 9 9.5. Authorization Server Mix-Up Mitigation . . . . . . . . . 11
9.6. Cross-Domain Requests . . . . . . . . . . . . . . . . . . 9 9.6. Cross-Domain Requests . . . . . . . . . . . . . . . . . . 12
9.7. Content-Security Policy . . . . . . . . . . . . . . . . . 10 9.7. Content-Security Policy . . . . . . . . . . . . . . . . . 12
9.8. OAuth Implicit Grant Authorization Flow . . . . . . . . . 10 9.8. OAuth Implicit Grant Authorization Flow . . . . . . . . . 12
9.8.1. Threat: Interception of the Redirect URI . . . . . . 10 9.8.1. Threat: Interception of the Redirect URI . . . . . . 13
9.8.2. Threat: Access Token Leak in Browser History . . . . 10 9.8.2. Threat: Access Token Leak in Browser History . . . . 13
9.8.3. Threat: Manipulation of Scripts . . . . . . . . . . . 10 9.8.3. Threat: Manipulation of Scripts . . . . . . . . . . . 13
9.8.4. Threat: Access Token Leak to Third Party Scripts . . 11 9.8.4. Threat: Access Token Leak to Third Party Scripts . . 13
9.8.5. Countermeasures . . . . . . . . . . . . . . . . . . . 11 9.8.5. Countermeasures . . . . . . . . . . . . . . . . . . . 14
9.8.6. Disadvantages of the Implicit Flow . . . . . . . . . 11 9.8.6. Disadvantages of the Implicit Flow . . . . . . . . . 14
9.8.7. Historic Note . . . . . . . . . . . . . . . . . . . . 12 9.8.7. Historic Note . . . . . . . . . . . . . . . . . . . . 15
9.9. Additional Security Considerations . . . . . . . . . . . 12 9.9. Additional Security Considerations . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Server Support Checklist . . . . . . . . . . . . . . 13 Appendix A. Server Support Checklist . . . . . . . . . . . . . . 16
Appendix B. Document History . . . . . . . . . . . . . . . . . . 14 Appendix B. Document History . . . . . . . . . . . . . . . . . . 16
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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
skipping to change at page 4, line 7 skipping to change at page 4, line 7
"OAuth": In this document, "OAuth" refers to OAuth 2.0, [RFC6749]. "OAuth": In this document, "OAuth" refers to OAuth 2.0, [RFC6749].
"Browser-based application": An application that is dynamically "Browser-based application": An application that is dynamically
downloaded and executed in a web browser, usually written in downloaded and executed in a web browser, usually written in
JavaScript. Also sometimes referred to as a "single-page JavaScript. Also sometimes referred to as a "single-page
application", or "SPA". application", or "SPA".
4. Overview 4. Overview
For authorizing users within a browser-based application, the best At the time that OAuth 2.0 RFC 6749 was created, browser-based
current practice is to JavaScript applications needed a solution that strictly complied with
the same-origin policy. Common deployments of OAuth 2.0 involved an
application running on a different domain than the authorization
server, so it was historically not possible to use the authorization
code flow which would require a cross-origin POST request. This was
the principal motivation for the definition of the implicit flow,
which returns the access token in the front channel via the fragment
part of the URL, bypassing the need for a cross-origin POST request.
o Use the OAuth 2.0 authorization code flow with the PKCE extension However, there are several drawbacks to the implicit flow, generally
involving vulnerabilities associated with the exposure of the access
token in the URL. See Section 9.8 for an analysis of these attacks
and the drawbacks of using the implicit flow in browsers. Additional
attacks and security considerations can be found in
[oauth-security-topics].
o Use the OAuth 2.0 state parameter to carry one-time use CSRF In recent years, widespread adoption of Cross-Origin Resource Sharing
tokens (CORS), which enables exceptions to the same-origin policy, allows
browser-based apps to use the OAuth 2.0 authorization code flow and
make a POST request to exchange the authorization code for an access
token at the token endpoint. In this flow, the access token is never
exposed in the less secure front-channel. Furthermore, adding PKCE
to the flow assures that even if an authorization code is
intercepted, it is unusable by an attacker.
o Recommend exact matching of redirect URIs, and require the For this reason, and from other lessons learned, the current best
hostname of the redirect URI match the hostname of the URL the app practice for browser-based applications is to use the OAuth 2.0
was served from authorization code flow with PKCE.
o Do not return access tokens in the front channel Applications should:
Since the publication of OAuth 2.0 RFC 6749, browsers have broadly o Use the OAuth 2.0 authorization code flow with the PKCE extension
adopted the concept of CORS, enabling the ability for JavaScript
applications to make cross-domain requests. During the time RFC 6749
was originally being written, browsers did not have wide support, so
it was not possible to require browsers to use the authorization code
flow, so the implicit flow was developed instead.
There are several drawbacks to the implicit flow, including the fact o Use the OAuth 2.0 state parameter to carry one-time use CSRF
that access tokens are returned in the front-channel via the fragment tokens
part of the redirect URI, and as such are vulnerable to a variety of
attacks where the access token can be intercepted or stolen. See
Section 9.8 for a deeper analysis of these attacks and the drawbacks
of using the implicit flow in browsers, many of which are described
by [oauth-security-topics].
Now, thanks to the wide adoption of CORS, browser-based apps can o Register one or more redirect URIs, and not vary the redirect URI
perform the OAuth 2.0 authorization code flow and make a POST request per authorization request
to the token endpoint to exchange an authorization code for an access
token, just like other OAuth clients. This ensures that access
tokens are not sent via the less secure front-channel, and are only
returned over an HTTPS connection initiated from the application.
Combined with PKCE, this enables the authorization server to ensure
that authorization codes are useless even if intercepted in
transport.
Historically, the Implicit flow provided an advantage to single-page OAuth 2.0 servers should:
apps since JavaScript could always arbitrarily read and manipulate
the fragment portion of the URL without triggering a page reload. o Require exact matching of registered redirect URIs
Now with the Session History API (described in "Session history and
navigation" of [HTML]), browsers have a mechanism to modify the path
component of the URL without triggering a page reload, so this
overloaded use of the fragment portion is no longer needed.
5. First-Party Applications 5. First-Party Applications
While OAuth and OpenID Connect were initially created to allow third- While OAuth and OpenID Connect were initially created to allow third-
party applications to access an API on behalf of a user, they have party applications to access an API on behalf of a user, they have
both proven to be useful in a first-party scenario as well. First- both proven to be useful in a first-party scenario as well. First-
party apps are applications where by the same organization that party apps are applications where by the same organization that
provides the API being accessed by the application. provides the API being accessed by the 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.
To conform to this best practice, first-party applications using To conform to this best practice, first-party applications using
OAuth or OpenID Connect MUST use an OAuth Authorization Code flow as OAuth or OpenID Connect MUST use the OAuth Authorization Code flow as
described later in this document or use the OAuth Password grant. described later in this document or use the OAuth Password grant.
It is strongly RECOMMENDED that applications use the Authorization It is strongly RECOMMENDED that applications use the Authorization
Code flow over the Password grant for several reasons. By Code flow over the Password grant for several reasons. By
redirecting to the authorization server, this provides the redirecting to the authorization server, this provides the
authorization server the opportunity to prompt the user for multi- authorization server the opportunity to prompt the user for multi-
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. Architectural Considerations 6. Application Architecture Patterns
In some cases, it may make sense to avoid the use of a strictly There are three primary architectural patterns available when
browser-based OAuth application entirely, and instead use an building browser-based applications.
architecture that keeps OAuth access tokens out of the browser.
6.1. Apps Served from a Common Domain as the API o JavaScript served from a common domain as the resource server
o JavaScript served from a dynamic application server
o JavaScript served from a static web server
These three architectures have different use cases and
considerations.
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
API's (resource server's) domain, it is likely a better decision to domain of the API (resource server), it is likely a better decision
avoid using OAuth entirely, and just use session authentication to to avoid using OAuth entirely, and just use session authentication to
communicate with the API. communicate directly with the API.
OAuth and OpenID Connect provide very little benefit in this OAuth and OpenID Connect provide very little benefit in this
deployment scenario, so it is recommended to reconsider whether you deployment scenario, so it is recommended to reconsider whether you
need OAuth or OpenID Connect at all in this case. Session need OAuth or OpenID Connect at all in this case. Session
authentication has the benefit of having fewer moving parts and fewer authentication has the benefit of having fewer moving parts and fewer
attack vectors. OAuth and OpenID Connect were created primarily for attack vectors. OAuth and OpenID Connect were created primarily for
third-party or federated access to APIs, so may not be the best third-party or federated access to APIs, so may not be the best
solution in a same-domain scenario. solution in a same-domain scenario.
6.2. Browser-Based App with a Backend Component 6.2. Apps Served from a Dynamic Application Server
+-------------+
| |
|Authorization|
| Server |
| |
+-------------+
To avoid the risks inherent in handling OAuth access tokens from a ^ +
purely browser-based application, implementations may wish to move |(A) |(B)
the authorization code exchange and handling of access and refresh | |
tokens into a backend component. + v
+-------------+ +--------------+
| | +---------> | |
| Application | (C) | Resource |
| Server | | Server |
| | <---------+ | |
+-------------+ (D) +--------------+
^ +
| |
| | browser
| | cookie
| |
+ v
+-------------+
| |
| Browser |
| |
+-------------+
In this architecture, the JavaScript code is loaded from a dynamic
Application Server that also has the ability to execute code itself.
This enables the ability to keep all of the steps involved in
obtaining an access token outside of the JavaScript application.
(Common examples of this architecture are an Angular front-end with a
.NET backend, or a React front-end with a Spring Boot backend.)
The Application Server SHOULD be considered a confidential client,
and issued its own client secret. The Application Server SHOULD use
the OAuth 2.0 authorization code grant to initiate a request request
for an access token. Upon handling the redirect from the
Authorization Server, the Application Server will request an access
token using the authorization code returned (A), which will be
returned to the Application Server (B). The Application Server
utilizes its own session with the browser to store the access token.
When the JavaScript application in the browser wants to make a
request to the Resource Server, it MUST instead make the request to
the Application Server, and the Application Server will make the
request with the access token to the Resource Server (C), and forward
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 backend component is assumed to utilize browser-level protection this Application Server is assumed to utilize browser-level
mechanisms. Details are out of scope of this document, but many protection mechanisms. Details are out of scope of this document,
recommendations can be found at the OWASP Foundation but many recommendations can be found at the OWASP Foundation
(https://www.owasp.org/). (https://www.owasp.org/), such as setting an HTTP-only and Secure
cookie to authenticate the session between the browser and
Application Server.
In this scenario, the backend component may be a confidential client In this scenario, the session between the browser and Application
which has the ability to authenticate itself. Despite this, there Server MAY be either a session cookie provided by the Application
are still some ways in which this application is effectively a public Server, OR the access token itself. Note that if the access token is
client, as the end result is the application's code is still running used as the session identifier, this exposes the access token to the
in the browser and visible to the user. Some authorization servers end user even if it is not available to the JavaScript application,
may have different policies for public and confidential clients, and so some authorization servers may wish to limit the capabilities of
this type of hybrid approach does not provide all the assurances of these clients to mitigate risk.
confidential clients that an authorization server is expecting.
Authorization servers may wish to treat this type of deployment as a 6.3. Apps Served from a Static Web Server
public client.
+---------------+ +--------------+
| | | |
| Authorization | | Resource |
| Server | | Server |
| | | |
+---------------+ +--------------+
^ + ^ +
| | | |
|(B) |(C) |(D) |(E)
| | | |
| | | |
+ v + v
+-----------------+ +-------------------------------+
| | (A) | |
| Static Web Host | +-----> | Browser |
| | | |
+-----------------+ +-------------------------------+
In this architecture, the JavaScript code is first loaded from a
static web host into the browser (A). The application then runs in
the browser, and is considered a public client since it has no
ability to be issued a client secret.
The code in the browser then initiates the authorization code flow
with the PKCE extension (described in Section 7) (B) above, and
obtains an access token via a POST request (C). The JavaScript app
is then responsible for storing the access token securely using
appropriate browser APIs.
When the JavaScript application in the browser wants to make a
request to the Resource Server, it can include the access token in
the request (D) and make the request directly.
In this scenario, the Authorization Server and Resource Server MUST
support the necessary CORS headers to enable the JavaScript code to
make this POST request from the domain on which the script is
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 needing user authorization create an
authorization request URI with the authorization code grant type per authorization request URI with the authorization code grant type per
Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of
being received by the app. 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
skipping to change at page 7, line 13 skipping to change at page 9, line 48
that initiated the flow. that initiated the flow.
Browser-based apps MUST use the OAuth 2.0 "state" parameter to Browser-based apps MUST use the OAuth 2.0 "state" parameter to
protect themselves against Cross-Site Request Forgery and protect themselves against Cross-Site Request Forgery and
authorization code swap attacks and MUST use a unique value for each authorization code swap attacks and MUST use a unique value for each
authorization request, and MUST verify the returned state in the authorization request, and MUST verify the returned state in the
authorization response matches the original state the app created. authorization response matches the original state the app created.
7.2. Handling the Authorization Code Redirect 7.2. Handling the Authorization Code Redirect
Authorization servers SHOULD require an exact match of a registered Authorization servers MUST require an exact match of a registered
redirect URI. redirect URI.
If an authorization server wishes to provide some flexibility in
redirect URI usage to clients, it MAY require that only the hostname
component of the redirect URI match the hostname of the URL the
application is served from.
Authorization servers MUST support one of the two redirect URI
validation mechanisms as described above.
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 stoken refresh token to obtain new access without
skipping to change at page 13, line 42 skipping to change at page 16, line 24
11.2. Informative References 11.2. Informative References
[HTML] whatwg, "HTML", 2018. [HTML] whatwg, "HTML", 2018.
Appendix A. Server Support Checklist Appendix A. Server Support Checklist
OAuth servers that support browser-based apps MUST: OAuth servers that support browser-based apps MUST:
1. Require "https" scheme redirect URIs. 1. Require "https" scheme redirect URIs.
2. Require exact matching on redirect URIs or matching the hostname 2. Require exact matching of registered redirect URIs.
the application is served from.
3. Support PKCE [RFC7636]. Required to protect authorization code 3. Support PKCE [RFC7636]. Required to protect authorization code
grants sent to public clients. See Section 7.1 grants sent to public clients. See Section 7.1
4. Support cross-domain requests at the token endpoint in order to 4. Support cross-domain requests at the token endpoint in order to
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 ]]
-02
o Rewrote overview section incorporating feedback from Leo Tohill
o Updated summary recommendation bullet points to split out
application and server requirements
o Removed the allowance on hostname-only redirect URI matching, now
requiring exact redirect URI matching
o Updated section 6.2 to drop reference of SPA with a backend
component being a public client
o Expanded the architecture section to explicitly mention three
architectural patterns available to JS apps
-01 -01
o Incorporated feedback from Torsten Lodderstedt o Incorporated feedback from Torsten Lodderstedt
o Updated abstract o Updated abstract
o Clarified the definition of browser-based apps to not exclude o Clarified the definition of browser-based apps to not exclude
applications cached in the browser, e.g. via Service Workers applications cached in the browser, e.g. via Service Workers
o Clarified use of the state parameter for CSRF protection o Clarified use of the state parameter for CSRF protection
skipping to change at page 14, line 44 skipping to change at page 17, line 40
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, John Bradley, Joseph
Heenan, Justin Richer, Karl McGuinness, Tomek Stojecki, Torsten Heenan, Justin Richer, Karl McGuinness, Leo Tohill, Tomek Stojecki,
Lodderstedt, and Vittorio Bertocci. 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. 30 change blocks. 
116 lines changed or deleted 219 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/