draft-ietf-oauth-browser-based-apps-03.txt   draft-ietf-oauth-browser-based-apps-04.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 25, 2020 Ping Identity Expires: March 25, 2020 Ping Identity
July 24, 2019 September 22, 2019
OAuth 2.0 for Browser-Based Apps OAuth 2.0 for Browser-Based Apps
draft-ietf-oauth-browser-based-apps-03 draft-ietf-oauth-browser-based-apps-04
Abstract Abstract
This specification details the security considerations that must be This specification details the security considerations and best
taken into account when developing browser-based applications, as practices that must be taken into account when developing browser-
well as best practices for how they can securely implement OAuth 2.0. based applications that use 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 25, 2020. This Internet-Draft will expire on March 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
skipping to change at page 2, line 13 skipping to change at page 2, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. First-Party Applications . . . . . . . . . . . . . . . . . . 4 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 . 5 6.1. Browser-Based Apps that Can Share Data with the Resource
Server . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.2. JavaScript Applications with a Backend . . . . . . . . . 6 6.2. JavaScript Applications with a Backend . . . . . . . . . 6
6.3. JavaScript Applications without a Backend . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 11
9.1. Registration of Browser-Based Apps . . . . . . . . . . . 10 9.1. Registration of Browser-Based Apps . . . . . . . . . . . 11
9.2. Client Authentication . . . . . . . . . . . . . . . . . . 10 9.2. Client Authentication . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . 12
9.5. Authorization Server Mix-Up Mitigation . . . . . . . . . 11 9.5. Authorization Server Mix-Up Mitigation . . . . . . . . . 12
9.6. Cross-Domain Requests . . . . . . . . . . . . . . . . . . 12 9.6. Cross-Domain Requests . . . . . . . . . . . . . . . . . . 12
9.7. Content-Security Policy . . . . . . . . . . . . . . . . . 12 9.7. Content-Security Policy . . . . . . . . . . . . . . . . . 13
9.8. OAuth Implicit Grant Authorization Flow . . . . . . . . . 12 9.8. OAuth Implicit Grant Authorization Flow . . . . . . . . . 13
9.8.1. Threat: Interception of the Redirect URI . . . . . . 13 9.8.1. Threat: Interception of the Redirect URI . . . . . . 13
9.8.2. Threat: Access Token Leak in Browser History . . . . 13 9.8.2. Threat: Access Token Leak in Browser History . . . . 13
9.8.3. Threat: Manipulation of Scripts . . . . . . . . . . . 13 9.8.3. Threat: Manipulation of Scripts . . . . . . . . . . . 14
9.8.4. Threat: Access Token Leak to Third Party Scripts . . 13 9.8.4. Threat: Access Token Leak to Third Party Scripts . . 14
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 . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Server Support Checklist . . . . . . . . . . . . . . 16 Appendix A. Server Support Checklist . . . . . . . . . . . . . . 17
Appendix B. Document History . . . . . . . . . . . . . . . . . . 16 Appendix B. Document History . . . . . . . . . . . . . . . . . . 17
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 18 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 25 skipping to change at page 4, line 25
make a POST request to exchange the authorization code for an access 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 token at the token endpoint. In this flow, the access token is never
exposed in the less secure front-channel. Furthermore, adding PKCE exposed in the less secure front-channel. Furthermore, adding PKCE
to the flow assures that even if an authorization code is to the flow assures that even if an authorization code is
intercepted, it is unusable by an attacker. intercepted, it is unusable by an attacker.
For this reason, and from other lessons learned, the current best For this reason, and from other lessons learned, the current best
practice for browser-based applications is to use the OAuth 2.0 practice for browser-based applications is to use the OAuth 2.0
authorization code flow with PKCE. authorization code flow with PKCE.
Applications should: Browser-based applications MUST:
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 Protect themselves against CSRF attacks by using the OAuth 2.0
tokens state parameter to carry one-time use CSRF tokens, or by ensuring
the authorization server supports PKCE
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 must: OAuth 2.0 authorization servers MUST:
o Require exact matching of registered redirect URIs o Require exact matching of registered redirect URIs
o Support the PKCE extension
5. First-Party Applications 5. First-Party Applications
While OAuth was initially created to allow third-party applications While OAuth was initially created to allow third-party applications
to access an API on behalf of a user, it has proven to be useful in a to access an API on behalf of a user, it has proven to be useful in a
first-party scenario as well. First-party apps are applications first-party scenario as well. First-party apps are applications
where the same organization provides both the API and the where the same organization provides both the API and 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.
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 the 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.
It is strongly RECOMMENDED that applications use the Authorization The Resource Owner Password Grant MUST NOT be used, as described in
Code flow over the Password grant for several reasons. By [oauth-security-topics] section 3.4.
redirecting to the authorization server, this provides the
authorization server the opportunity to prompt the user for multi- By using the Authorization Code flow and redirecting the user to the
factor authentication options, take advantage of single-sign-on authorization server, this provides the authorization server the
sessions, or use third-party identity providers. In contrast, the opportunity to prompt the user for multi-factor authentication
Password grant does not provide any built-in mechanism for these, and options, take advantage of single-sign-on sessions, or use third-
must be extended with custom code. party identity providers. In contrast, the Password grant does not
provide any built-in mechanism for these, and would instead 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 a JavaScript application served from a common domain as the o a JavaScript application with no backend, accessing resource
resource server servers directly
o a JavaScript application with a backend o a JavaScript application with a backend
o a JavaScript application with no backend, accessing resource o a JavaScript application that has methods of sharing data with
servers directly resource servers, such as using common-domain cookies
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. Browser-Based Apps that Can Share Data with 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), OAuth adds additional attack domain of the API (resource server), OAuth adds additional attack
vectors that could be avoided with a different solution. vectors that could be avoided with a different solution.
In particular, using any redirect-based mechanism of obtaining an In particular, using any redirect-based mechanism of obtaining an
access token enables the redirect-based attacks described in access token enables the redirect-based attacks described in
[oauth-security-topics], but if the application, AS and API share a [oauth-security-topics], but if the application, AS and API share a
domain, then it is unnecessary to use a redirect mechanism to domain, then it is unnecessary to use a redirect mechanism to
communicate between them. communicate between them.
An additional concern with handling access tokens in a browser is An additional concern with handling access tokens in a browser is
that there is no secure storage mechanism where JavaScript code can 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 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, OAuth flow results in the JavaScript code getting an access token,
needing to store it somewhere, and then retrieve it to make an API 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 request. Instead, a more secure design is to use an HTTP-only cookie
between the JavaScript application and API so that the JavaScript between the JavaScript application and API so that the JavaScript
code can't access the cookie value itself. code can't access the cookie value itself.
In this situation, it is best to avoid letting the JavaScript code OAuth was originally created for third-party or federated access to
ever see the access token, and instead use a mechanism such as the APIs, so it may not be the best solution in a common-domain
"JavaScript Applications with a Backend" pattern described below, to deployment. That said, using OAuth even in a common-domain
keep access tokens out of the browser. architecture does mean you can more easily rearchitect things later,
such as if you were to later add a new domain to the system.
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 6.2. JavaScript Applications with a Backend
+-------------+ +-------------+
| | | |
|Authorization| |Authorization|
| Server | | Server |
| | | |
+-------------+ +-------------+
^ + ^ +
skipping to change at page 9, line 39 skipping to change at page 9, line 39
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,
by providing the authorization server with a way to verify the same by providing the authorization server with a way to verify the same
client instance that exchanges the authorization code is the same one client instance that exchanges the authorization code is the same one
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 a unique value for the the OAuth 2.0
protect themselves against Cross-Site Request Forgery and "state" parameter on each request, and MUST verify the returned state
authorization code swap attacks and MUST use a unique value for each in the authorization response matches the original state the app
authorization request, and MUST verify the returned state in the created.
authorization response matches the original state the app created.
Browser-based apps MUST follow the recommendations in
[oauth-security-topics] section 3.1 to protect themselves during
redirect flows.
7.2. Handling the Authorization Code Redirect 7.2. Handling the Authorization Code Redirect
Authorization servers MUST require an exact match of a registered Authorization servers MUST require an exact match of a registered
redirect URI. redirect URI.
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. With public clients,
describes some additional requirements around refresh tokens on top the risk of a leaked refresh token is greater than leaked access
of the recommendations of [RFC6749]. tokens, since an attacker may be able to continue using the stolen
refresh token to obtain new access tokens potentially without being
detectable by the authorization server.
For public clients, the risk of a leaked refresh token is much Browser-based applications provide an attacker with several
greater than leaked access tokens, since an attacker can potentially opportunities by which a refresh token can be leaked, just as with
continue using the stolen refresh token to obtain new access tokens access tokens. As such, these applications are considered a higher
without being detectable by the authorization server. Additionally, risk for handling refresh tokens.
browser-based applications provide many attack vectors by which a
refresh token can be leaked. As such, these applications are
considered a higher risk for handling refresh tokens.
Authorization servers SHOULD NOT issue refresh tokens to browser- [oauth-security-topics] describes some additional requirements around
based applications. refresh tokens on top of the recommendations of [RFC6749].
Applications and authorization servers conforming to this BCP MUST
also follow the recommendations in [oauth-security-topics] around
refresh tokens.
If an authorization server does choose to issue refresh tokens to In particular, authorization servers:
browser-based applications, then it MUST issue a new refresh token
with every access token refresh response. Doing this mitigates the o MUST rotate refresh tokens on each use, in order to be able to
risk of a leaked refresh token, as a leaked refresh token can be detect a stolen refresh token if one is replayed (described in
detected if both the attacker and the legitimate client attempt to [oauth-security-topics] section 4.12)
use the same refresh token. Authorization servers MUST follow the
additional refresh token replay mitigation techniques described in o MUST either set a maximum lifetime on refresh tokens OR expire if
[oauth-security-topics]. the refresh token has not been used within some amount of time
o upon issuing a rotated refresh token, MUST NOT extend the lifetime
of the new refresh token beyond the lifetime of the initial
refresh token if the refresh token has a preestablished expiration
time
For example:
o A user authorizes an application, issuing an access token that
lasts 1 hour, and a refresh token that lasts 24 hours
o After 1 hour, the initial access token expires, so the application
uses the refresh token to get a new access token
o The authorization server returns a new access token that lasts 1
hour, and a new refresh token that lasts 23 hours
o This continues until 24 hours pass from the initial authorization
o At this point, when the application attempts to use the refresh
token after 24 hours, the request will fail and the application
will have to involve the user in a new authorization request
By limiting the overall refresh token lifetime to the lifetime of the
initial refresh token, this ensures a stolen refresh token cannot be
used indefinitely.
9. Security Considerations 9. Security Considerations
9.1. Registration of Browser-Based Apps 9.1. Registration of Browser-Based Apps
Browser-based applications are considered public clients as defined Browser-based applications are considered public clients as defined
by section 2.1 of OAuth 2.0 [RFC6749], and MUST be registered with by section 2.1 of OAuth 2.0 [RFC6749], and MUST be registered with
the authorization server as such. Authorization servers MUST record the authorization server as such. Authorization servers MUST record
the client type in the client registration details in order to the client type in the client registration details in order to
identify and process requests accordingly. identify and process requests accordingly.
skipping to change at page 11, line 43 skipping to change at page 12, line 22
accepted by authorization servers as proof of identity of the client accepted by authorization servers as proof of identity of the client
for the purpose of deciding whether to automatically process an for the purpose of deciding whether to automatically process an
authorization request when a previous request for the client_id has authorization request when a previous request for the client_id has
already been approved. already been approved.
9.4. Cross-Site Request Forgery Protections 9.4. Cross-Site Request Forgery Protections
Section 5.3.5 of [RFC6819] recommends using the "state" parameter to Section 5.3.5 of [RFC6819] recommends using the "state" parameter to
link client requests and responses to prevent CSRF (Cross-Site link client requests and responses to prevent CSRF (Cross-Site
Request Forgery) attacks. To conform to this best practice, use of Request Forgery) attacks. To conform to this best practice, use of
the "state" parameter is REQUIRED, as described in Section 7.1. the "state" parameter is REQUIRED, as described in Section 7.1,
unless the application has a method of ensuring the authorization
server supports PKCE, since PKCE also prevents CSRF attacks.
9.5. Authorization Server Mix-Up Mitigation 9.5. Authorization Server Mix-Up Mitigation
The security considerations around the authorization server mix-up The security considerations around the authorization server mix-up
that are referenced in Section 8.10 of [RFC8252] also apply to that are referenced in Section 8.10 of [RFC8252] also apply to
browser-based apps. browser-based apps.
Clients MUST use a unique redirect URI for each authorization server Clients MUST use a unique redirect URI for each authorization server
used by the application. The client MUST store the redirect URI used by the application. The client MUST store the redirect URI
along with the session data (e.g. along with "state") and MUST verify along with the session data (e.g. along with "state") and MUST verify
skipping to change at page 14, line 28 skipping to change at page 15, line 8
There are several additional reasons the Implicit flow is There are several additional reasons the Implicit flow is
disadvantageous compared to using the standard Authorization Code disadvantageous compared to using the standard Authorization Code
flow. flow.
o OAuth 2.0 provides no mechanism for a client to verify that an o OAuth 2.0 provides no mechanism for a client to verify that an
access token was issued to it, which could lead to misuse and access token was issued to it, which could lead to misuse and
possible impersonation attacks if a malicious party hands off an possible impersonation attacks if a malicious party hands off an
access token it retrieved through some other means to the client. access token it retrieved through some other means to the client.
o Returning an access token in the front channel redirect gives the o Returning an access token in the front channel redirect gives the
authorization server little assurance that the access token will authorization server no assurance that the access token will
actually end up at the application, since there are many ways this actually end up at the application, since there are many ways this
redirect may fail or be intercepted. redirect may fail or be intercepted.
o Supporting the implicit flow requires additional code, more upkeep o Supporting the implicit flow requires additional code, more upkeep
and understanding of the related security considerations, while and understanding of the related security considerations, while
limiting the authorization server to just the authorization code limiting the authorization server to just the authorization code
flow reduces the attack surface of the implementation. flow reduces the attack surface of the implementation.
o If the JavaScript application gets wrapped into a native app, then o If the JavaScript application gets wrapped into a native app, then
[RFC8252] also requires the use of the authorization code flow [RFC8252] also requires the use of the authorization code flow
with PKCE anyway. with PKCE anyway.
In OpenID Connect, the id_token is sent in a known format (as a JWT), In OpenID Connect, the id_token is sent in a known format (as a JWT),
and digitally signed. Performing OpenID Connect using the and digitally signed. Returning an id_token using the Implicit flow
authorization code flow also provides the additional benefit of the (response_type=id_token) requires the client validate the JWT
client not needing to verify the JWT signature, as the token will signature, as malicious parties could otherwise craft and supply
have been fetched over an HTTPS connection directly from the fraudulent id_tokens. Performing OpenID Connect using the
authorization server. However, returning an id_token using the authorization code flow provides the benefit of the client not
Implicit flow requires the client validate the JWT signature, as needing to verify the JWT signature, as the ID token will have been
malicious parties could otherwise craft and supply fraudulent fetched over an HTTPS connection directly from the authorization
id_tokens. server. Additionally, in many cases an application will request both
an ID token and an access token, so it is simplier and provides fewer
attack vectors to obtain both via the authorization code flow.
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.
This was necessary in order to remove the access token from the URL This was necessary in order to remove the access token from the URL
after it was obtained by the app. after it was obtained by the app.
Modern browsers now have the Session History API (described in Modern browsers now have the Session History API (described in
skipping to change at page 16, line 29 skipping to change at page 17, line 11
[RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", [RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,
<https://www.rfc-editor.org/info/rfc8252>. <https://www.rfc-editor.org/info/rfc8252>.
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 authorization servers that support browser-based apps MUST:
1. Require "https" scheme redirect URIs. 1. Require "https" scheme redirect URIs.
2. Require exact matching of registered redirect URIs. 2. Require exact matching of registered redirect URIs.
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.
6. Not support the Resource Owner Password grant for browser-based
clients.
7. Follow the [oauth-security-topics] recommendations on refresh
tokens, as well as the additional requirements described in
Section 8.
Appendix B. Document History Appendix B. Document History
[[ To be removed from the final specification ]] [[ To be removed from the final specification ]]
-04
o Disallow the use of the Password Grant
o Add PKCE support to summary list for authorization server
requirements
o Rewrote refresh token section to allow refresh tokens if they are
time-limited, rotated on each use, and requiring that the rotated
refresh token lifetimes do not extend past the lifetime of the
initial refresh token, and to bring it in line with the Security
BCP
o Updated recommendations on using state to reflect the Security BCP
o Updated server support checklist to reflect latest changes
o Updated the same-domain JS architecture section to emphasize the
architecture rather than domain
o Editorial clarifications in the section that talks about OpenID
Connect ID tokens
-03 -03
o Updated the historic note about the fragment URL clarifying that o Updated the historic note about the fragment URL clarifying that
the Session History API means browsers can use the unmodified the Session History API means browsers can use the unmodified
authorization code flow authorization code flow
o Rephrased "Authorization Code Flow" intro paragraph to better lead o Rephrased "Authorization Code Flow" intro paragraph to better lead
into the next two sections into the next two sections
o Softened "is likely a better decision to avoid using OAuth o Softened "is likely a better decision to avoid using OAuth
entirely" to "it may be..." for common-domain deployments entirely" to "it may be..." for common-domain deployments
 End of changes. 33 change blocks. 
92 lines changed or deleted 156 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/