draft-ietf-oauth-browser-based-apps-06.txt   draft-ietf-oauth-browser-based-apps-07.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: October 7, 2020 Ping Identity Expires: April 5, 2021 Ping Identity
April 05, 2020 October 02, 2020
OAuth 2.0 for Browser-Based Apps OAuth 2.0 for Browser-Based Apps
draft-ietf-oauth-browser-based-apps-06 draft-ietf-oauth-browser-based-apps-07
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 October 7, 2020. This Internet-Draft will expire on April 5, 2021.
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 11 skipping to change at page 2, line 11
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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 5
6. Application Architecture Patterns . . . . . . . . . . . . . . 5 6. Application Architecture Patterns . . . . . . . . . . . . . . 5
6.1. Browser-Based Apps that Can Share Data with the Resource 6.1. Browser-Based Apps that Can Share Data with the Resource
Server . . . . . . . . . . . . . . . . . . . . . . . . . 5 Server . . . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . . 10 Application . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Handling the Authorization Code Redirect . . . . . . . . 10 7.2. Handling the Authorization Code Redirect . . . . . . . . 10
8. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . . . 10 8. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9.1. Registration of Browser-Based Apps . . . . . . . . . . . 12 9.1. Registration of Browser-Based Apps . . . . . . . . . . . 11
9.2. Client Authentication . . . . . . . . . . . . . . . . . . 12 9.2. Client Authentication . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . 12
9.5. Authorization Server Mix-Up Mitigation . . . . . . . . . 13 9.5. Authorization Server Mix-Up Mitigation . . . . . . . . . 12
9.6. Cross-Domain Requests . . . . . . . . . . . . . . . . . . 13 9.6. Cross-Domain Requests . . . . . . . . . . . . . . . . . . 13
9.7. Content-Security Policy . . . . . . . . . . . . . . . . . 14 9.7. Content-Security Policy . . . . . . . . . . . . . . . . . 13
9.8. OAuth Implicit Flow . . . . . . . . . . . . . . . . . . . 14 9.8. OAuth Implicit Flow . . . . . . . . . . . . . . . . . . . 13
9.8.1. Attacks on the Implicit Flow . . . . . . . . . . . . 14 9.8.1. Attacks on the Implicit Flow . . . . . . . . . . . . 13
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 . . . . . . . . . . . 17 9.9. Additional Security Considerations . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Server Support Checklist . . . . . . . . . . . . . . 18 Appendix A. Server Support Checklist . . . . . . . . . . . . . . 17
Appendix B. Document History . . . . . . . . . . . . . . . . . . 18 Appendix B. Document History . . . . . . . . . . . . . . . . . . 18
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 20 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 executing implementing OAuth 2.0 authorization flows in applications executing
in a browser. 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 22 skipping to change at page 4, line 22
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 ensures that even if an authorization code is to the flow ensures 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.
Browser-based applications MUST: Browser-based applications:
o Use the OAuth 2.0 authorization code flow with the PKCE extension o MUST use the OAuth 2.0 authorization code flow with the PKCE
extension when obtaining an access token
o Protect themselves against CSRF attacks by ensuring the o MUST Protect themselves against CSRF attacks by either:
authorization server supports PKCE, or by using the OAuth 2.0
"state" parameter or the OpenID Connect "nonce" parameter to carry
one-time use CSRF tokens
o Register one or more redirect URIs, and use only exact registered * ensuring the authorization server supports PKCE, or
redirect URIs in authorization requests
OAuth 2.0 authorization servers MUST: * by using the OAuth 2.0 "state" parameter or the OpenID Connect
"nonce" parameter to carry one-time use CSRF tokens
o Require exact matching of registered redirect URIs o MUST Register one or more redirect URIs, and use only exact
registered redirect URIs in authorization requests
o Support the PKCE extension OAuth 2.0 authorization servers:
o MUST Require exact matching of registered redirect URIs
o MUST Support the PKCE extension
o MUST NOT issue access tokens in the authorization response
o If issuing refresh tokens to browser-based apps, then: o If issuing refresh tokens to browser-based apps, then:
o Rotate refresh tokens on each use * SHOULD rotate refresh tokens on each use, and
o Set a maximum lifetime on refresh tokens or expire if they are not * MUST set a maximum lifetime on refresh tokens or expire if they
used in some amount of time 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
skipping to change at page 7, line 4 skipping to change at page 7, line 4
attribute can be used to prevent CSRF attacks, or alternatively, the attribute can be used to prevent CSRF attacks, or alternatively, the
application and API could be written to use anti-CSRF tokens. application and API could be written to use anti-CSRF tokens.
OAuth was originally created for third-party or federated access to OAuth was originally created for third-party or federated access to
APIs, so it may not be the best solution in a common-domain APIs, so it may not be the best solution in a common-domain
deployment. That said, using OAuth even in a common-domain deployment. That said, using OAuth even in a common-domain
architecture does mean you can more easily rearchitect things later, architecture does mean you can more easily rearchitect things later,
such as if you were to later add a new domain to the system. such as if you were to later add a new domain to the system.
6.2. JavaScript Applications with a Backend 6.2. JavaScript Applications with a Backend
+-------------+ +-------------+ +--------------+ +---------------+
| | | | | | | |
|Authorization| |Authorization| | Token | | Resource |
| Server | | Endpoint | | Endpoint | | Server |
| | | | | | | |
+-------------+ +-------------+ +--------------+ +---------------+
^ +
|(A) |(B)
| |
+ v
+-------------+ +--------------+
| | +---------> | |
| Application | (C) | Resource |
| Server | | Server |
| | <---------+ | |
+-------------+ (D) +--------------+
^ + ^ ^ ^
| | | (D)| (G)|
| | browser | v v
| | cookie |
| | | +--------------------------------+
+ v | | |
| | Application |
(B)| | Server |
| | |
| +--------------------------------+
|
| ^ ^ + ^ +
| (A)| (C)| (E)| (F)| |(H)
v v + v + v
+-------------+ +-------------------------------------------------+
| | | |
| Browser | | Browser |
| | | |
+-------------+ +-------------------------------------------------+
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 (A) that also has the ability to execute code
This enables the ability to keep all of the steps involved in itself. This enables the ability to keep all of the steps involved
obtaining an access token outside of the JavaScript application. in obtaining an access token outside of the JavaScript application.
In this case, the Application Server performs the OAuth flow itself, In this case, the Application Server initiates the OAuth flow itself,
and keeps the access token and refresh token stored internally, by redirecting the browser to the authorization endpoint (B). When
creating a separate session with the browser-based app via a the user is redirected back, the browser delivers the authorization
traditional browser cookie. code to the application server (C), where it can then exchange it for
an access token at the token endpoint (D) using its client secret.
The application server then keeps the access token and refresh token
stored internally, and creates a separate session with the browser-
based app via a traditional browser cookie (E).
When the JavaScript application in the browser wants to make a
request to the Resource Server, it instead makes the request to the
Application Server (F), and the Application Server will make the
request with the access token to the Resource Server (H), and forward
the response (H) back to the browser.
(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 for an the OAuth 2.0 Authorization Code grant with PKCE to initiate a
access token. Upon handling the redirect from the Authorization request for an access token.
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 stores this access
token itself and establishes its own cookie-based session with the
Browser application. The Application Server can store the access
token either server-side, or in the cookie itself.
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 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,
but many recommendations can be found in the OWASP Cheat Sheet series but many recommendations can be found in the OWASP Cheat Sheet series
(https://cheatsheetseries.owasp.org/), such as setting an HTTP-only (https://cheatsheetseries.owasp.org/), such as setting an HTTP-only
and Secure cookie to authenticate the session between the browser and and Secure cookie to authenticate the session between the browser and
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 SHOULD be a session cookie provided by the Application Server.
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
end user even if it is not available to the JavaScript application,
so some authorization servers may wish to limit the capabilities of
these clients to mitigate risk.
6.3. JavaScript Applications without a Backend 6.3. JavaScript Applications without a Backend
+---------------+ +--------------+ +---------------+ +--------------+
| | | | | | | |
| Authorization | | Resource | | Authorization | | Resource |
| Server | | Server | | Server | | Server |
| | | | | | | |
+---------------+ +--------------+ +---------------+ +--------------+
^ + ^ + ^ + ^ +
| | | | | | | |
|(B) |(C) |(D) |(E) |(B) |(C) |(D) |(E)
skipping to change at page 10, line 9 skipping to change at page 9, line 30
7. Authorization Code Flow 7. Authorization Code Flow
Public browser-based apps that use the authorization code grant type Public browser-based apps that use the authorization code grant type
described in Section 4.1 of OAuth 2.0 [RFC6749] MUST also follow described in Section 4.1 of OAuth 2.0 [RFC6749] MUST also follow
these additional requirements described in this section. these additional requirements described in this section.
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 when obtaining an access token,
servers MUST support PKCE for such clients. and authorization servers MUST support and enforce 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 prevent CSRF attacks against their redirect Browser-based apps MUST prevent CSRF attacks against their redirect
URI. This can be accomplished by any of the below: URI. This can be accomplished by any of the below:
o using PKCE, and confirming that the authorization server supports o using PKCE, and confirming that the authorization server supports
PKCE PKCE
o using a unique value for the OAuth 2.0 "state" parameter
o if the application is using OpenID Connect, by using the OpenID o if the application is using OpenID Connect, by using the OpenID
Connect "nonce" parameter Connect "nonce" parameter
o using a unique value for the OAuth 2.0 "state" parameter
Browser-based apps MUST follow the recommendations in Browser-based apps MUST follow the recommendations in
[oauth-security-topics] Section 2.1 to protect themselves during [oauth-security-topics] Section 2.1 to protect themselves during
redirect flows. 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
skipping to change at page 11, line 15 skipping to change at page 10, line 38
Authorization servers may choose whether or not to issue refresh Authorization servers may choose whether or not to issue refresh
tokens to browser-based applications. [oauth-security-topics] tokens to browser-based applications. [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]. Applications and authorization of the recommendations of [RFC6749]. Applications and authorization
servers conforming to this BCP MUST also follow the recommendations servers conforming to this BCP MUST also follow the recommendations
in [oauth-security-topics] around refresh tokens if refresh tokens in [oauth-security-topics] around refresh tokens if refresh tokens
are issued to browser-based apps. are issued to browser-based apps.
In particular, authorization servers: In particular, authorization servers:
o MUST rotate refresh tokens on each use, in order to be able to o SHOULD rotate refresh tokens on each use, in order to be able to
detect a stolen refresh token if one is replayed (described in detect a stolen refresh token if one is replayed (described in
[oauth-security-topics] section 4.12) [oauth-security-topics] section 4.12)
o MUST either set a maximum lifetime on refresh tokens OR expire if o MUST either set a maximum lifetime on refresh tokens OR expire if
the refresh token has not been used within some amount of time the refresh token has not been used within some amount of time
o upon issuing a rotated refresh token, MUST NOT extend the lifetime o upon issuing a rotated refresh token, MUST NOT extend the lifetime
of the new refresh token beyond the lifetime of the initial of the new refresh token beyond the lifetime of the initial
refresh token if the refresh token has a preestablished expiration refresh token if the refresh token has a preestablished expiration
time time
skipping to change at page 11, line 48 skipping to change at page 11, line 24
o This continues until 24 hours pass from the initial authorization o This continues until 24 hours pass from the initial authorization
o At this point, when the application attempts to use the refresh o At this point, when the application attempts to use the refresh
token after 24 hours, the request will fail and the application token after 24 hours, the request will fail and the application
will have to involve the user in a new authorization request will have to involve the user in a new authorization request
By limiting the overall refresh token lifetime to the lifetime of the By limiting the overall refresh token lifetime to the lifetime of the
initial refresh token, this ensures a stolen refresh token cannot be initial refresh token, this ensures a stolen refresh token cannot be
used indefinitely. used indefinitely.
Authorization servers MAY set different policies around refresh token
issuance, lifetime and expiration for browser-based apps compared to
other public clients.
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.
Authorization servers MUST require that browser-based applications Authorization servers MUST require that browser-based applications
register one or more redirect URIs. register one or more redirect URIs.
skipping to change at page 14, line 17 skipping to change at page 13, line 37
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.
9.8. OAuth Implicit Flow 9.8. OAuth Implicit Flow
The OAuth 2.0 Implicit flow (defined in Section 4.2 of OAuth 2.0 The OAuth 2.0 Implicit flow (defined in Section 4.2 of OAuth 2.0
[RFC6749]) works by receiving an access token in the HTTP redirect [RFC6749]) works by the authorization server issuing an access token
(front-channel) immediately without the code exchange step. In this in the authorization response (front-channel) without the code
case, the access token is returned in the fragment part of the exchange step. In this case, the access token is returned in the
redirect URI, providing an attacker with several opportunities to fragment part of the redirect URI, providing an attacker with several
intercept and steal the access token. opportunities to intercept and steal the access token.
Authorization servers MUST NOT issue access tokens in the
authorization response, and MUST issue access tokens only from the
token endpoint.
9.8.1. Attacks on the Implicit Flow 9.8.1. Attacks on the Implicit Flow
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
skipping to change at page 16, line 23 skipping to change at page 15, line 45
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. Returning an id_token using the Implicit flow and digitally signed. Returning an id_token using the Implicit flow
(response_type=id_token) requires the client validate the JWT ("response_type=id_token") requires the client validate the JWT
signature, as malicious parties could otherwise craft and supply signature, as malicious parties could otherwise craft and supply
fraudulent id_tokens. Performing OpenID Connect using the fraudulent id_tokens. Performing OpenID Connect using the
authorization code flow provides the benefit of the client not authorization code flow provides the benefit of the client not
needing to verify the JWT signature, as the ID token will have been needing to verify the JWT signature, as the ID token will have been
fetched over an HTTPS connection directly from the authorization fetched over an HTTPS connection directly from the authorization
server. Additionally, in many cases an application will request both server. Additionally, in many cases an application will request both
an ID token and an access token, so it is simplier and provides fewer an ID token and an access token, so it is simplier and provides fewer
attack vectors to obtain both via the authorization code flow. attack vectors to obtain both via the authorization code flow.
9.8.4. Historic Note 9.8.4. Historic Note
skipping to change at page 18, line 42 skipping to change at page 18, line 13
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 ]]
-07
o Clarify PKCE requirements apply only to issuing access tokens
o Change "MUST" to "SHOULD" for refresh token rotation
o Editorial clarifications
-06 -06
o Added refresh token requirements to AS summary o Added refresh token requirements to AS summary
o Editorial clarifications o Editorial clarifications
-05 -05
o Incorporated editorial and substantive feedback from Mike Jones o Incorporated editorial and substantive feedback from Mike Jones
 End of changes. 37 change blocks. 
102 lines changed or deleted 115 lines changed or added

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