draft-ietf-oauth-browser-based-apps-05.txt   draft-ietf-oauth-browser-based-apps-06.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: August 31, 2020 Ping Identity Expires: October 7, 2020 Ping Identity
February 28, 2020 April 05, 2020
OAuth 2.0 for Browser-Based Apps OAuth 2.0 for Browser-Based Apps
draft-ietf-oauth-browser-based-apps-05 draft-ietf-oauth-browser-based-apps-06
Abstract Abstract
This specification details the security considerations and best This specification details the security considerations and best
practices that must be taken into account when developing browser- practices that must be taken into account when developing browser-
based applications that use 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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 August 31, 2020. This Internet-Draft will expire on October 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 35 skipping to change at page 2, line 35
9.3. Client Impersonation . . . . . . . . . . . . . . . . . . 12 9.3. Client Impersonation . . . . . . . . . . . . . . . . . . 12
9.4. Cross-Site Request Forgery Protections . . . . . . . . . 13 9.4. Cross-Site Request Forgery Protections . . . . . . . . . 13
9.5. Authorization Server Mix-Up Mitigation . . . . . . . . . 13 9.5. Authorization Server Mix-Up Mitigation . . . . . . . . . 13
9.6. Cross-Domain Requests . . . . . . . . . . . . . . . . . . 13 9.6. Cross-Domain Requests . . . . . . . . . . . . . . . . . . 13
9.7. Content-Security Policy . . . . . . . . . . . . . . . . . 14 9.7. Content-Security Policy . . . . . . . . . . . . . . . . . 14
9.8. OAuth Implicit Flow . . . . . . . . . . . . . . . . . . . 14 9.8. OAuth Implicit Flow . . . . . . . . . . . . . . . . . . . 14
9.8.1. Attacks on the Implicit Flow . . . . . . . . . . . . 14 9.8.1. Attacks on the Implicit Flow . . . . . . . . . . . . 14
9.8.2. Countermeasures . . . . . . . . . . . . . . . . . . . 15 9.8.2. Countermeasures . . . . . . . . . . . . . . . . . . . 15
9.8.3. Disadvantages of the Implicit Flow . . . . . . . . . 15 9.8.3. Disadvantages of the Implicit Flow . . . . . . . . . 15
9.8.4. Historic Note . . . . . . . . . . . . . . . . . . . . 16 9.8.4. Historic Note . . . . . . . . . . . . . . . . . . . . 16
9.9. Additional Security Considerations . . . . . . . . . . . 16 9.9. Additional Security Considerations . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Server Support Checklist . . . . . . . . . . . . . . 18 Appendix A. Server Support Checklist . . . . . . . . . . . . . . 18
Appendix B. Document History . . . . . . . . . . . . . . . . . . 18 Appendix B. Document History . . . . . . . . . . . . . . . . . . 18
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 20 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
skipping to change at page 4, line 40 skipping to change at page 4, line 40
o Register one or more redirect URIs, and use only exact registered o Register one or more redirect URIs, and use only exact registered
redirect URIs in authorization requests redirect URIs in authorization requests
OAuth 2.0 authorization 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 o Support the PKCE extension
o If issuing refresh tokens to browser-based apps, then:
o Rotate refresh tokens on each use
o Set a maximum lifetime on refresh tokens or expire if they are not
used in some amount of time
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.
Examples of first-party applications are a web email client provided Examples of first-party applications are a web email client provided
by the operator of the email account, or a mobile banking application by the operator of the email account, or a mobile banking application
skipping to change at page 14, line 34 skipping to change at page 14, line 34
Many attacks on the implicit flow described by [RFC6819] and Many attacks on the implicit flow described by [RFC6819] and
[oauth-security-topics] do not have sufficient mitigation strategies. [oauth-security-topics] do not have sufficient mitigation strategies.
The following sections describe the specific attacks that cannot be The following sections describe the specific attacks that cannot be
mitigated while continuing to use the implicit flow. mitigated while continuing to use the implicit flow.
9.8.1.1. Threat: Interception of the Redirect URI 9.8.1.1. Threat: Interception of the Redirect URI
If an attacker is able to cause the authorization response to be sent If an attacker is able to cause the authorization response to be sent
to a URI under their control, they will directly get access to the to a URI under their control, they will directly get access to the
fragment carrying the access token. Several methods of performing authorization response including the access token. Several methods
this attack are described in detail in [oauth-security-topics]. of performing this attack are described in detail in
[oauth-security-topics].
9.8.1.2. Threat: Access Token Leak in Browser History 9.8.1.2. Threat: Access Token Leak in Browser History
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
skipping to change at page 15, line 38 skipping to change at page 15, line 38
of the application may not be able to be fully aware of the entirety of the application may not be able to be fully aware of the entirety
of the code running in the application. When an access token is of the code running in the application. When an access token is
returned in the fragment, it is visible to any third-party scripts on returned in the fragment, it is visible to any third-party scripts on
the page. the page.
9.8.2. Countermeasures 9.8.2. Countermeasures
In addition to the countermeasures described by [RFC6819] and In addition to the countermeasures described by [RFC6819] and
[oauth-security-topics], using the authorization code with PKCE [oauth-security-topics], using the authorization code with PKCE
extension prevents the attacks described above by avoiding returning extension prevents the attacks described above by avoiding returning
the access token in the redirect URI at all. the access token in the redirect response at all.
When PKCE is used, if an authorization code is stolen in transport, When PKCE is used, if an authorization code is stolen in transport,
the attacker is unable to do anything with the authorization code. the attacker is unable to do anything with the authorization code.
9.8.3. Disadvantages of the Implicit Flow 9.8.3. Disadvantages of the Implicit Flow
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 a
access token was issued to it, which could lead to misuse and particular access token was intended for that client, which could
possible impersonation attacks if a malicious party hands off an lead to misuse and possible impersonation attacks if a malicious
access token it retrieved through some other means to the client. party hands off an 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 no 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
skipping to change at page 18, line 38 skipping to change at page 18, line 42
clients. clients.
7. Follow the [oauth-security-topics] recommendations on refresh 7. Follow the [oauth-security-topics] recommendations on refresh
tokens, as well as the additional requirements described in tokens, as well as the additional requirements described in
Section 8. Section 8.
Appendix B. Document History Appendix B. Document History
[[ To be removed from the final specification ]] [[ To be removed from the final specification ]]
-06
o Added refresh token requirements to AS summary
o Editorial clarifications
-05 -05
o Incorporated editorial and substantive feedback from Mike Jones o Incorporated editorial and substantive feedback from Mike Jones
o Added references to "nonce" as another way to prevent CSRF attacks o Added references to "nonce" as another way to prevent CSRF attacks
o Updated headers in the Implicit Flow section to better represent o Updated headers in the Implicit Flow section to better represent
the relationship between the paragraphs the relationship between the paragraphs
-04 -04
o Disallow the use of the Password Grant o Disallow the use of the Password Grant
o Add PKCE support to summary list for authorization server o Add PKCE support to summary list for authorization server
requirements requirements
 End of changes. 11 change blocks. 
14 lines changed or deleted 28 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/