draft-ietf-oauth-security-topics-14.txt   draft-ietf-oauth-security-topics-15.txt 
Web Authorization Protocol T. Lodderstedt Web Authorization Protocol T. Lodderstedt
Internet-Draft yes.com Internet-Draft yes.com
Intended status: Best Current Practice J. Bradley Intended status: Best Current Practice J. Bradley
Expires: August 13, 2020 Yubico Expires: 7 October 2020 Yubico
A. Labunets A. Labunets
D. Fett D. Fett
yes.com yes.com
February 10, 2020 5 April 2020
OAuth 2.0 Security Best Current Practice OAuth 2.0 Security Best Current Practice
draft-ietf-oauth-security-topics-14 draft-ietf-oauth-security-topics-15
Abstract Abstract
This document describes best current security practice for OAuth 2.0. This document describes best current security practice for OAuth 2.0.
It updates and extends the OAuth 2.0 Security Threat Model to It updates and extends the OAuth 2.0 Security Threat Model to
incorporate practical experiences gathered since OAuth 2.0 was incorporate practical experiences gathered since OAuth 2.0 was
published and covers new threats relevant due to the broader published and covers new threats relevant due to the broader
application of OAuth 2.0. application of OAuth 2.0.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 13, 2020. This Internet-Draft will expire on 7 October 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as 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
1.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions and Terminology . . . . . . . . . . . . . . . 4 1.2. Conventions and Terminology . . . . . . . . . . . . . . . 4
2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Protecting Redirect-Based Flows . . . . . . . . . . . . . 5 2.1. Protecting Redirect-Based Flows . . . . . . . . . . . . . 5
2.1.1. Authorization Code Grant . . . . . . . . . . . . . . 6 2.1.1. Authorization Code Grant . . . . . . . . . . . . . . 6
2.1.2. Implicit Grant . . . . . . . . . . . . . . . . . . . 6 2.1.2. Implicit Grant . . . . . . . . . . . . . . . . . . . 6
2.2. Token Replay Prevention . . . . . . . . . . . . . . . . . 7 2.2. Token Replay Prevention . . . . . . . . . . . . . . . . . 7
2.3. Access Token Privilege Restriction . . . . . . . . . . . 7 2.3. Access Token Privilege Restriction . . . . . . . . . . . 7
2.4. Resource Owner Password Credentials Grant . . . . . . . . 8 2.4. Resource Owner Password Credentials Grant . . . . . . . . 8
2.5. Client Authentication . . . . . . . . . . . . . . . . . . 8 2.5. Client Authentication . . . . . . . . . . . . . . . . . . 8
2.6. Other Recommendations . . . . . . . . . . . . . . . . . . 8 2.6. Other Recommendations . . . . . . . . . . . . . . . . . . 8
3. The Updated OAuth 2.0 Attacker Model . . . . . . . . . . . . 8 3. The Updated OAuth 2.0 Attacker Model . . . . . . . . . . . . 9
4. Attacks and Mitigations . . . . . . . . . . . . . . . . . . . 10 4. Attacks and Mitigations . . . . . . . . . . . . . . . . . . . 11
4.1. Insufficient Redirect URI Validation . . . . . . . . . . 11 4.1. Insufficient Redirect URI Validation . . . . . . . . . . 11
4.1.1. Redirect URI Validation Attacks on Authorization Code 4.1.1. Redirect URI Validation Attacks on Authorization Code
Grant . . . . . . . . . . . . . . . . . . . . . . . . 11 Grant . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2. Redirect URI Validation Attacks on Implicit Grant . . 13 4.1.2. Redirect URI Validation Attacks on Implicit Grant . . 13
4.1.3. Countermeasures . . . . . . . . . . . . . . . . . . . 14 4.1.3. Countermeasures . . . . . . . . . . . . . . . . . . . 14
4.2. Credential Leakage via Referer Headers . . . . . . . . . 15 4.2. Credential Leakage via Referer Headers . . . . . . . . . 15
4.2.1. Leakage from the OAuth Client . . . . . . . . . . . . 15 4.2.1. Leakage from the OAuth Client . . . . . . . . . . . . 15
4.2.2. Leakage from the Authorization Server . . . . . . . . 15 4.2.2. Leakage from the Authorization Server . . . . . . . . 15
4.2.3. Consequences . . . . . . . . . . . . . . . . . . . . 16 4.2.3. Consequences . . . . . . . . . . . . . . . . . . . . 16
4.2.4. Countermeasures . . . . . . . . . . . . . . . . . . . 16 4.2.4. Countermeasures . . . . . . . . . . . . . . . . . . . 16
skipping to change at page 3, line 4 skipping to change at page 2, line 51
4.5. Authorization Code Injection . . . . . . . . . . . . . . 21 4.5. Authorization Code Injection . . . . . . . . . . . . . . 21
4.5.1. Attack Description . . . . . . . . . . . . . . . . . 21 4.5.1. Attack Description . . . . . . . . . . . . . . . . . 21
4.5.2. Discussion . . . . . . . . . . . . . . . . . . . . . 22 4.5.2. Discussion . . . . . . . . . . . . . . . . . . . . . 22
4.5.3. Countermeasures . . . . . . . . . . . . . . . . . . . 23 4.5.3. Countermeasures . . . . . . . . . . . . . . . . . . . 23
4.5.4. Limitations . . . . . . . . . . . . . . . . . . . . . 24 4.5.4. Limitations . . . . . . . . . . . . . . . . . . . . . 24
4.6. Access Token Injection . . . . . . . . . . . . . . . . . 24 4.6. Access Token Injection . . . . . . . . . . . . . . . . . 24
4.6.1. Countermeasures . . . . . . . . . . . . . . . . . . . 25 4.6.1. Countermeasures . . . . . . . . . . . . . . . . . . . 25
4.7. Cross Site Request Forgery . . . . . . . . . . . . . . . 25 4.7. Cross Site Request Forgery . . . . . . . . . . . . . . . 25
4.7.1. Countermeasures . . . . . . . . . . . . . . . . . . . 25 4.7.1. Countermeasures . . . . . . . . . . . . . . . . . . . 25
4.8. Access Token Leakage at the Resource Server . . . . . . . 25 4.8. Access Token Leakage at the Resource Server . . . . . . . 25
4.8.1. Access Token Phishing by Counterfeit Resource Server 26 4.8.1. Access Token Phishing by Counterfeit Resource
Server . . . . . . . . . . . . . . . . . . . . . . . 26
4.8.2. Compromised Resource Server . . . . . . . . . . . . . 31 4.8.2. Compromised Resource Server . . . . . . . . . . . . . 31
4.9. Open Redirection . . . . . . . . . . . . . . . . . . . . 31 4.9. Open Redirection . . . . . . . . . . . . . . . . . . . . 31
4.9.1. Client as Open Redirector . . . . . . . . . . . . . . 32 4.9.1. Client as Open Redirector . . . . . . . . . . . . . . 32
4.9.2. Authorization Server as Open Redirector . . . . . . . 32 4.9.2. Authorization Server as Open Redirector . . . . . . . 32
4.10. 307 Redirect . . . . . . . . . . . . . . . . . . . . . . 32 4.10. 307 Redirect . . . . . . . . . . . . . . . . . . . . . . 32
4.11. TLS Terminating Reverse Proxies . . . . . . . . . . . . . 33 4.11. TLS Terminating Reverse Proxies . . . . . . . . . . . . . 33
4.12. Refresh Token Protection . . . . . . . . . . . . . . . . 34 4.12. Refresh Token Protection . . . . . . . . . . . . . . . . 34
4.12.1. Discussion . . . . . . . . . . . . . . . . . . . . . 34 4.12.1. Discussion . . . . . . . . . . . . . . . . . . . . . 34
4.12.2. Recommendations . . . . . . . . . . . . . . . . . . 35 4.12.2. Recommendations . . . . . . . . . . . . . . . . . . 35
4.13. Client Impersonating Resource Owner . . . . . . . . . . . 36 4.13. Client Impersonating Resource Owner . . . . . . . . . . . 36
4.13.1. Countermeasures . . . . . . . . . . . . . . . . . . 36 4.13.1. Countermeasures . . . . . . . . . . . . . . . . . . 36
4.14. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 36 4.14. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 36
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 8. Normative References . . . . . . . . . . . . . . . . . . . . 38
8.1. Normative References . . . . . . . . . . . . . . . . . . 38 9. Informative References . . . . . . . . . . . . . . . . . . . 39
8.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Document History . . . . . . . . . . . . . . . . . . 42 Appendix A. Document History . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
Since its publication in [RFC6749] and [RFC6750], OAuth 2.0 ("OAuth" Since its publication in [RFC6749] and [RFC6750], OAuth 2.0 ("OAuth"
in the following) has gotten massive traction in the market and in the following) has gotten massive traction in the market and
became the standard for API protection and the basis for federated became the standard for API protection and the basis for federated
login using OpenID Connect [OpenID]. While OAuth is used in a login using OpenID Connect [OpenID]. While OAuth is used in a
variety of scenarios and different kinds of deployments, the variety of scenarios and different kinds of deployments, the
following challenges can be observed: following challenges can be observed:
o OAuth implementations are being attacked through known * OAuth implementations are being attacked through known
implementation weaknesses and anti-patterns. Although most of implementation weaknesses and anti-patterns. Although most of
these threats are discussed in the OAuth 2.0 Threat Model and these threats are discussed in the OAuth 2.0 Threat Model and
Security Considerations [RFC6819], continued exploitation Security Considerations [RFC6819], continued exploitation
demonstrates a need for more specific recommendations, easier to demonstrates a need for more specific recommendations, easier to
implement mitigations, and more defense in depth. implement mitigations, and more defense in depth.
o OAuth is being used in environments with higher security * OAuth is being used in environments with higher security
requirements than considered initially, such as Open Banking, requirements than considered initially, such as Open Banking,
eHealth, eGovernment, and Electronic Signatures. Those use cases eHealth, eGovernment, and Electronic Signatures. Those use cases
call for stricter guidelines and additional protection. call for stricter guidelines and additional protection.
o OAuth is being used in much more dynamic setups than originally * OAuth is being used in much more dynamic setups than originally
anticipated, creating new challenges with respect to security. anticipated, creating new challenges with respect to security.
Those challenges go beyond the original scope of [RFC6749], Those challenges go beyond the original scope of [RFC6749],
[RFC6750], and [RFC6819]. [RFC6750], and [RFC6819].
OAuth initially assumed a static relationship between client, OAuth initially assumed a static relationship between client,
authorization server and resource servers. The URLs of AS and RS authorization server and resource servers. The URLs of AS and RS
were known to the client at deployment time and built an anchor were known to the client at deployment time and built an anchor
for the trust relationship among those parties. The validation for the trust relationship among those parties. The validation
whether the client talks to a legitimate server was based on TLS whether the client talks to a legitimate server was based on TLS
server authentication (see [RFC6819], Section 4.5.4). With the server authentication (see [RFC6819], Section 4.5.4). With the
skipping to change at page 4, line 23 skipping to change at page 4, line 23
relationship between clients on one side and the authorization and relationship between clients on one side and the authorization and
resource servers of a particular deployment on the other side. resource servers of a particular deployment on the other side.
This way, the same client could be used to access services of This way, the same client could be used to access services of
different providers (in case of standard APIs, such as e-mail or different providers (in case of standard APIs, such as e-mail or
OpenID Connect) or serve as a frontend to a particular tenant in a OpenID Connect) or serve as a frontend to a particular tenant in a
multi-tenancy environment. Extensions of OAuth, such as the OAuth multi-tenancy environment. Extensions of OAuth, such as the OAuth
2.0 Dynamic Client Registration Protocol [RFC7591] and OAuth 2.0 2.0 Dynamic Client Registration Protocol [RFC7591] and OAuth 2.0
Authorization Server Metadata [RFC8414] were developed in order to Authorization Server Metadata [RFC8414] were developed in order to
support the usage of OAuth in dynamic scenarios. support the usage of OAuth in dynamic scenarios.
o Technology has changed. For example, the way browsers treat * Technology has changed. For example, the way browsers treat
fragments when redirecting requests has changed, and with it, the fragments when redirecting requests has changed, and with it, the
implicit grant's underlying security model. implicit grant's underlying security model.
This document provides updated security recommendations to address This document provides updated security recommendations to address
these challenges. It does not supplant the security advice given in these challenges. It does not supplant the security advice given in
[RFC6749], [RFC6750], and [RFC6819], but complements those documents. [RFC6749], [RFC6750], and [RFC6819], but complements those documents.
1.1. Structure 1.1. Structure
The remainder of this document is organized as follows: The next The remainder of this document is organized as follows: The next
skipping to change at page 6, line 29 skipping to change at page 6, line 29
When using PKCE, clients SHOULD use PKCE code challenge methods that When using PKCE, clients SHOULD use PKCE code challenge methods that
do not expose the PKCE verifier in the authorization request. do not expose the PKCE verifier in the authorization request.
Otherwise, attackers that can read the authorization request (cf. Otherwise, attackers that can read the authorization request (cf.
Attacker A4 in Section 3) can break the security provided by PKCE. Attacker A4 in Section 3) can break the security provided by PKCE.
Currently, "S256" is the only such method. Currently, "S256" is the only such method.
Authorization servers MUST support PKCE [RFC7636]. Authorization servers MUST support PKCE [RFC7636].
Authorization servers MUST provide a way to detect their support for Authorization servers MUST provide a way to detect their support for
PKCE. To this end, they MUST either (a) publish the element PKCE. To this end, they MUST either (a) publish the element
"code_challenge_methods_supported" in their AS metadata ([RFC8418]) "code_challenge_methods_supported" in their AS metadata ([RFC8414])
containing the supported PKCE challenge methods (which can be used by containing the supported PKCE challenge methods (which can be used by
the client to detect PKCE support) or (b) provide a deployment- the client to detect PKCE support) or (b) provide a deployment-
specific way to ensure or determine PKCE support by the AS. specific way to ensure or determine PKCE support by the AS.
2.1.2. Implicit Grant 2.1.2. Implicit Grant
The implicit grant (response type "token") and other response types The implicit grant (response type "token") and other response types
causing the authorization server to issue access tokens in the causing the authorization server to issue access tokens in the
authorization response are vulnerable to access token leakage and authorization response are vulnerable to access token leakage and
access token replay as described in Section 4.1, Section 4.2, access token replay as described in Section 4.1, Section 4.2,
skipping to change at page 9, line 13 skipping to change at page 9, line 19
protected. In the following, this attacker model is updated to protected. In the following, this attacker model is updated to
account for the potentially dynamic relationships involving multiple account for the potentially dynamic relationships involving multiple
parties (as described in Section 1), to include new types of parties (as described in Section 1), to include new types of
attackers and to define the attacker model more clearly. attackers and to define the attacker model more clearly.
OAuth MUST ensure that the authorization of the resource owner (RO) OAuth MUST ensure that the authorization of the resource owner (RO)
(with a user agent) at the authorization server (AS) and the (with a user agent) at the authorization server (AS) and the
subsequent usage of the access token at the resource server (RS) is subsequent usage of the access token at the resource server (RS) is
protected at least against the following attackers: protected at least against the following attackers:
o (A1) Web Attackers that can set up and operate an arbitrary number * (A1) Web Attackers that can set up and operate an arbitrary number
of network endpoints including browsers and servers (except for of network endpoints including browsers and servers (except for
the concrete RO, AS, and RS). Web attackers may set up web sites the concrete RO, AS, and RS). Web attackers may set up web sites
that are visited by the RO, operate their own user agents, and that are visited by the RO, operate their own user agents, and
participate in the protocol. participate in the protocol.
Web attackers may, in particular, operate OAuth clients that are Web attackers may, in particular, operate OAuth clients that are
registered at AS, and operate their own authorization and resource registered at AS, and operate their own authorization and resource
servers that can be used (in parallel) by the RO and other servers that can be used (in parallel) by the RO and other
resource owners. resource owners.
It must also be assumed that web attackers can lure the user to It must also be assumed that web attackers can lure the user to
open arbitrary attacker-chosen URIs at any time. In practice, open arbitrary attacker-chosen URIs at any time. In practice,
this can be achieved in many ways, for example, by injecting this can be achieved in many ways, for example, by injecting
malicious advertisements into advertisement networks, or by malicious advertisements into advertisement networks, or by
sending legit-looking emails. sending legit-looking emails.
Web attackers can use their own user credentials to create new Web attackers can use their own user credentials to create new
messages as well as any secrets they learned previously. For messages as well as any secrets they learned previously. For
example, if a web attacker learns an authorization code of a user example, if a web attacker learns an authorization code of a user
through a misconfigured redirect URI, the web attacker can then through a misconfigured redirect URI, the web attacker can then
try to redeem that code for an access token. try to redeem that code for an access token.
They cannot, however, read or manipulate messages that are not They cannot, however, read or manipulate messages that are not
targeted towards them (e.g., sent to a URL controlled by a non- targeted towards them (e.g., sent to a URL controlled by a non-
attacker controlled AS). attacker controlled AS).
o (A2) Network Attackers that additionally have full control over * (A2) Network Attackers that additionally have full control over
the network over which protocol participants communicate. They the network over which protocol participants communicate. They
can eavesdrop on, manipulate, and spoof messages, except when can eavesdrop on, manipulate, and spoof messages, except when
these are properly protected by cryptographic methods (e.g., TLS). these are properly protected by cryptographic methods (e.g., TLS).
Network attackers can also block arbitrary messages. Network attackers can also block arbitrary messages.
While an example for a web attacker would be a customer of an While an example for a web attacker would be a customer of an
internet service provider, network attackers could be the internet internet service provider, network attackers could be the internet
service provider itself, an attacker in a public (wifi) network using service provider itself, an attacker in a public (wifi) network using
ARP spoofing, or a state-sponsored attacker with access to internet ARP spoofing, or a state-sponsored attacker with access to internet
exchange points, for instance. exchange points, for instance.
These attackers conform to the attacker model that was used in formal These attackers conform to the attacker model that was used in formal
analysis efforts for OAuth [arXiv.1601.01229]. This is a minimal analysis efforts for OAuth [arXiv.1601.01229]. This is a minimal
attacker model. Implementers MUST take into account all possible attacker model. Implementers MUST take into account all possible
attackers in the environment in which their OAuth implementations are attackers in the environment in which their OAuth implementations are
expected to run. Previous attacks on OAuth have shown that OAuth expected to run. Previous attacks on OAuth have shown that OAuth
deployments SHOULD in particular consider the following, stronger deployments SHOULD in particular consider the following, stronger
attackers in addition to those listed above: attackers in addition to those listed above:
o (A3) Attackers that can read, but not modify, the contents of the * (A3) Attackers that can read, but not modify, the contents of the
authorization response (i.e., the authorization response can leak authorization response (i.e., the authorization response can leak
to an attacker). to an attacker).
Examples for such attacks include open redirector attacks, Examples for such attacks include open redirector attacks,
problems existing on mobile operating systems (where different problems existing on mobile operating systems (where different
apps can register themselves on the same URI), mix-up attacks (see apps can register themselves on the same URI), mix-up attacks (see
Section 4.4), where the client is tricked into sending credentials Section 4.4), where the client is tricked into sending credentials
to a attacker-controlled AS, and the fact that URLs are often to a attacker-controlled AS, and the fact that URLs are often
stored/logged by browsers (history), proxy servers, and operating stored/logged by browsers (history), proxy servers, and operating
systems. systems.
o (A4) Attackers that can read, but not modify, the contents of the * (A4) Attackers that can read, but not modify, the contents of the
authorization request (i.e., the authorization request can leak, authorization request (i.e., the authorization request can leak,
in the same manner as above, to an attacker). in the same manner as above, to an attacker).
o (A5) Attackers that can acquire an access token issued by AS. For * (A5) Attackers that can acquire an access token issued by AS. For
example, a resource server can be compromised by an attacker, an example, a resource server can be compromised by an attacker, an
access token may be sent to an attacker-controlled resource server access token may be sent to an attacker-controlled resource server
due to a misconfiguration, or an RO is social-engineered into due to a misconfiguration, or an RO is social-engineered into
using a attacker-controlled RS. See also Section 4.8.2. using a attacker-controlled RS. See also Section 4.8.2.
(A3), (A4) and (A5) typically occur together with either (A1) or (A3), (A4) and (A5) typically occur together with either (A1) or
(A2). (A2).
Note that in this attacker model, an attacker (see A1) can be a RO or Note that in this attacker model, an attacker (see A1) can be a RO or
act as one. For example, an attacker can use his own browser to act as one. For example, an attacker can use his own browser to
skipping to change at page 11, line 24 skipping to change at page 11, line 31
This approach turned out to be more complex to implement and more This approach turned out to be more complex to implement and more
error prone to manage than exact redirect URI matching. Several error prone to manage than exact redirect URI matching. Several
successful attacks exploiting flaws in the pattern matching successful attacks exploiting flaws in the pattern matching
implementation or concrete configurations have been observed in the implementation or concrete configurations have been observed in the
wild . Insufficient validation of the redirect URI effectively breaks wild . Insufficient validation of the redirect URI effectively breaks
client identification or authentication (depending on grant and client identification or authentication (depending on grant and
client type) and allows the attacker to obtain an authorization code client type) and allows the attacker to obtain an authorization code
or access token, either or access token, either
o by directly sending the user agent to a URI under the attackers * by directly sending the user agent to a URI under the attackers
control, or control, or
o by exposing the OAuth credentials to an attacker by utilizing an * by exposing the OAuth credentials to an attacker by utilizing an
open redirector at the client in conjunction with the way user open redirector at the client in conjunction with the way user
agents handle URL fragments. agents handle URL fragments.
These attacks are shown in detail in the following subsections. These attacks are shown in detail in the following subsections.
4.1.1. Redirect URI Validation Attacks on Authorization Code Grant 4.1.1. Redirect URI Validation Attacks on Authorization Code Grant
For a client using the grant type code, an attack may work as For a client using the grant type code, an attack may work as
follows: follows:
skipping to change at page 14, line 38 skipping to change at page 14, line 42
The complexity of implementing and managing pattern matching The complexity of implementing and managing pattern matching
correctly obviously causes security issues. This document therefore correctly obviously causes security issues. This document therefore
advises to simplify the required logic and configuration by using advises to simplify the required logic and configuration by using
exact redirect URI matching only. This means the authorization exact redirect URI matching only. This means the authorization
server MUST compare the two URIs using simple string comparison as server MUST compare the two URIs using simple string comparison as
defined in [RFC3986], Section 6.2.1. defined in [RFC3986], Section 6.2.1.
Additional recommendations: Additional recommendations:
o Servers on which callbacks are hosted MUST NOT expose open * Servers on which callbacks are hosted MUST NOT expose open
redirectors (see Section 4.9). redirectors (see Section 4.9).
o Browsers reattach URL fragments to Location redirection URLs only * Browsers reattach URL fragments to Location redirection URLs only
if the URL in the Location header does not already contain a if the URL in the Location header does not already contain a
fragment. Therefore, servers MAY prevent browsers from fragment. Therefore, servers MAY prevent browsers from
reattaching fragments to redirection URLs by attaching an reattaching fragments to redirection URLs by attaching an
arbitrary fragment identifier, for example "#_", to URLs in arbitrary fragment identifier, for example "#_", to URLs in
Location headers. Location headers.
o Clients SHOULD use the authorization code response type instead of * Clients SHOULD use the authorization code response type instead of
response types causing access token issuance at the authorization response types causing access token issuance at the authorization
endpoint. This offers countermeasures against reuse of leaked endpoint. This offers countermeasures against reuse of leaked
credentials through the exchange process with the authorization credentials through the exchange process with the authorization
server and token replay through sender-constraining of the access server and token replay through sender-constraining of the access
tokens. tokens.
If the origin and integrity of the authorization request containing If the origin and integrity of the authorization request containing
the redirect URI can be verified, for example when using the redirect URI can be verified, for example when using
[I-D.ietf-oauth-jwsreq] or [I-D.ietf-oauth-par] with client [I-D.ietf-oauth-jwsreq] or [I-D.ietf-oauth-par] with client
authentication, the authorization server MAY trust the redirect URI authentication, the authorization server MAY trust the redirect URI
skipping to change at page 15, line 30 skipping to change at page 15, line 35
in this way. Although specified otherwise in [RFC7231], in this way. Although specified otherwise in [RFC7231],
Section 5.5.2, the same may happen to access tokens conveyed in URI Section 5.5.2, the same may happen to access tokens conveyed in URI
fragments due to browser implementation issues as illustrated by fragments due to browser implementation issues as illustrated by
Chromium Issue 168213 [bug.chromium]. Chromium Issue 168213 [bug.chromium].
4.2.1. Leakage from the OAuth Client 4.2.1. Leakage from the OAuth Client
Leakage from the OAuth client requires that the client, as a result Leakage from the OAuth client requires that the client, as a result
of a successful authorization request, renders a page that of a successful authorization request, renders a page that
o contains links to other pages under the attacker's control and a * contains links to other pages under the attacker's control and a
user clicks on such a link, or user clicks on such a link, or
o includes third-party content (advertisements in iframes, images, * includes third-party content (advertisements in iframes, images,
etc.), for example if the page contains user-generated content etc.), for example if the page contains user-generated content
(blog). (blog).
As soon as the browser navigates to the attacker's page or loads the As soon as the browser navigates to the attacker's page or loads the
third-party content, the attacker receives the authorization response third-party content, the attacker receives the authorization response
URL and can extract "code" or "state" (and potentially "access URL and can extract "code" or "state" (and potentially "access
token"). token").
4.2.2. Leakage from the Authorization Server 4.2.2. Leakage from the Authorization Server
skipping to change at page 16, line 22 skipping to change at page 16, line 22
4.2.4. Countermeasures 4.2.4. Countermeasures
The page rendered as a result of the OAuth authorization response and The page rendered as a result of the OAuth authorization response and
the authorization endpoint SHOULD NOT include third-party resources the authorization endpoint SHOULD NOT include third-party resources
or links to external sites. or links to external sites.
The following measures further reduce the chances of a successful The following measures further reduce the chances of a successful
attack: attack:
o Suppress the Referer header by applying an appropriate Referrer * Suppress the Referer header by applying an appropriate Referrer
Policy [webappsec-referrer-policy] to the document (either as part Policy [webappsec-referrer-policy] to the document (either as part
of the "referrer" meta attribute or by setting a Referrer-Policy of the "referrer" meta attribute or by setting a Referrer-Policy
header). For example, the header "Referrer-Policy: no-referrer" header). For example, the header "Referrer-Policy: no-referrer"
in the response completely suppresses the Referer header in all in the response completely suppresses the Referer header in all
requests originating from the resulting document. requests originating from the resulting document.
o Use authorization code instead of response types causing access * Use authorization code instead of response types causing access
token issuance from the authorization endpoint. token issuance from the authorization endpoint.
o Bind authorization code to a confidential client or PKCE * Bind authorization code to a confidential client or PKCE
challenge. In this case, the attacker lacks the secret to request challenge. In this case, the attacker lacks the secret to request
the code exchange. the code exchange.
o As described in [RFC6749], Section 4.1.2, authorization codes MUST * As described in [RFC6749], Section 4.1.2, authorization codes MUST
be invalidated by the AS after their first use at the token be invalidated by the AS after their first use at the token
endpoint. For example, if an AS invalidated the code after the endpoint. For example, if an AS invalidated the code after the
legitimate client redeemed it, the attacker would fail exchanging legitimate client redeemed it, the attacker would fail exchanging
this code later. this code later.
This does not mitigate the attack if the attacker manages to This does not mitigate the attack if the attacker manages to
exchange the code for a token before the legitimate client does exchange the code for a token before the legitimate client does
so. Therefore, [RFC6749] further recommends that, when an attempt so. Therefore, [RFC6749] further recommends that, when an attempt
is made to redeem a code twice, the AS SHOULD revoke all tokens is made to redeem a code twice, the AS SHOULD revoke all tokens
issued previously based on that code. issued previously based on that code.
o The "state" value SHOULD be invalidated by the client after its * The "state" value SHOULD be invalidated by the client after its
first use at the redirection endpoint. If this is implemented, first use at the redirection endpoint. If this is implemented,
and an attacker receives a token through the Referer header from and an attacker receives a token through the Referer header from
the client's web site, the "state" was already used, invalidated the client's web site, the "state" was already used, invalidated
by the client and cannot be used again by the attacker. (This by the client and cannot be used again by the attacker. (This
does not help if the "state" leaks from the AS's web site, since does not help if the "state" leaks from the AS's web site, since
then the "state" has not been used at the redirection endpoint at then the "state" has not been used at the redirection endpoint at
the client yet.) the client yet.)
o Use the form post response mode instead of a redirect for the * Use the form post response mode instead of a redirect for the
authorization response (see [oauth-v2-form-post-response-mode]). authorization response (see [oauth-v2-form-post-response-mode]).
4.3. Credential Leakage via Browser History 4.3. Credential Leakage via Browser History
Authorization codes and access tokens can end up in the browser's Authorization codes and access tokens can end up in the browser's
history of visited URLs, enabling the attacks described in the history of visited URLs, enabling the attacks described in the
following. following.
4.3.1. Authorization Code in Browser History 4.3.1. Authorization Code in Browser History
When a browser navigates to "client.example/ When a browser navigates to "client.example/
redirection_endpoint?code=abcd" as a result of a redirect from a redirection_endpoint?code=abcd" as a result of a redirect from a
provider's authorization endpoint, the URL including the provider's authorization endpoint, the URL including the
authorization code may end up in the browser's history. An attacker authorization code may end up in the browser's history. An attacker
with access to the device could obtain the code and try to replay it. with access to the device could obtain the code and try to replay it.
Countermeasures: Countermeasures:
o Authorization code replay prevention as described in [RFC6819], * Authorization code replay prevention as described in [RFC6819],
Section 4.4.1.1, and Section 4.5. Section 4.4.1.1, and Section 4.5.
o Use form post response mode instead of redirect for the * Use form post response mode instead of redirect for the
authorization response (see [oauth-v2-form-post-response-mode]). authorization response (see [oauth-v2-form-post-response-mode]).
4.3.2. Access Token in Browser History 4.3.2. Access Token in Browser History
An access token may end up in the browser history if a client or a An access token may end up in the browser history if a client or a
web site that already has a token deliberately navigates to a page web site that already has a token deliberately navigates to a page
like "provider.com/get_user_profile?access_token=abcdef". [RFC6750] like "provider.com/get_user_profile?access_token=abcdef". [RFC6750]
discourages this practice and advises to transfer tokens via a discourages this practice and advises to transfer tokens via a
header, but in practice web sites often pass access tokens in query header, but in practice web sites often pass access tokens in query
parameters. parameters.
In case of the implicit grant, a URL like "client.example/ In case of the implicit grant, a URL like "client.example/
redirection_endpoint#access_token=abcdef" may also end up in the redirection_endpoint#access_token=abcdef" may also end up in the
browser history as a result of a redirect from a provider's browser history as a result of a redirect from a provider's
authorization endpoint. authorization endpoint.
Countermeasures: Countermeasures:
o Clients MUST NOT pass access tokens in a URI query parameter in * Clients MUST NOT pass access tokens in a URI query parameter in
the way described in Section 2.3 of [RFC6750]. The authorization the way described in Section 2.3 of [RFC6750]. The authorization
code grant or alternative OAuth response modes like the form post code grant or alternative OAuth response modes like the form post
response mode [oauth-v2-form-post-response-mode] can be used to response mode [oauth-v2-form-post-response-mode] can be used to
this end. this end.
4.4. Mix-Up Attacks 4.4. Mix-Up Attacks
Mix-up is an attack on scenarios where an OAuth client interacts with Mix-up is an attack on scenarios where an OAuth client interacts with
two or more authorization servers and at least one authorization two or more authorization servers and at least one authorization
server is under the control of the attacker. This can be the case, server is under the control of the attacker. This can be the case,
skipping to change at page 18, line 30 skipping to change at page 18, line 30
at the respective endpoint of the uncompromised authorization/ at the respective endpoint of the uncompromised authorization/
resource server. resource server.
4.4.1. Attack Description 4.4.1. Attack Description
The description here closely follows [arXiv.1601.01229], with The description here closely follows [arXiv.1601.01229], with
variants of the attack outlined below. variants of the attack outlined below.
Preconditions: For this variant of the attack to work, we assume that Preconditions: For this variant of the attack to work, we assume that
o the implicit or authorization code grant are used with multiple AS * the implicit or authorization code grant are used with multiple AS
of which one is considered "honest" (H-AS) and one is operated by of which one is considered "honest" (H-AS) and one is operated by
the attacker (A-AS), the attacker (A-AS),
o the client stores the AS chosen by the user in a session bound to * the client stores the AS chosen by the user in a session bound to
the user's browser and uses the same redirection endpoint URI for the user's browser and uses the same redirection endpoint URI for
each AS, and each AS, and
o the attacker can intercept and manipulate the first request/ * the attacker can intercept and manipulate the first request/
response pair from a user's browser to the client (in which the response pair from a user's browser to the client (in which the
user selects a certain AS and is then redirected by the client to user selects a certain AS and is then redirected by the client to
that AS), as in Attacker A2. that AS), as in Attacker A2.
The latter ability can, for example, be the result of a man-in-the- The latter ability can, for example, be the result of a man-in-the-
middle attack on the user's connection to the client. Note that an middle attack on the user's connection to the client. Note that an
attack variant exists that does not require this ability, see below. attack variant exists that does not require this ability, see below.
In the following, we assume that the client is registered with H-AS In the following, we assume that the client is registered with H-AS
(URI: "https://honest.as.example", client ID: "7ZGZldHQ") and with (URI: "https://honest.as.example", client ID: "7ZGZldHQ") and with
skipping to change at page 19, line 38 skipping to change at page 19, line 38
6. Since the client still assumes that the code was issued by A-AS, 6. Since the client still assumes that the code was issued by A-AS,
it will try to redeem the code at A-AS's token endpoint. it will try to redeem the code at A-AS's token endpoint.
7. The attacker therefore obtains code and can either exchange the 7. The attacker therefore obtains code and can either exchange the
code for an access token (for public clients) or perform an code for an access token (for public clients) or perform an
authorization code injection attack as described in Section 4.5. authorization code injection attack as described in Section 4.5.
Variants: Variants:
o *Mix-Up Without Interception*: A variant of the above attack works * *Mix-Up Without Interception*: A variant of the above attack works
even if the first request/response pair cannot be intercepted, for even if the first request/response pair cannot be intercepted, for
example, because TLS is used to protect these messages: Here, it example, because TLS is used to protect these messages: Here, it
is assumed that the user wants to start the grant using A-AS (and is assumed that the user wants to start the grant using A-AS (and
not H-AS, see Attacker A1). After the client redirected the user not H-AS, see Attacker A1). After the client redirected the user
to the authorization endpoint at A-AS, the attacker immediately to the authorization endpoint at A-AS, the attacker immediately
redirects the user to H-AS (changing the client ID to "7ZGZldHQ"). redirects the user to H-AS (changing the client ID to "7ZGZldHQ").
Note that a vigilant user might at this point detect that she Note that a vigilant user might at this point detect that she
intended to use A-AS instead of H-AS. The attack now proceeds intended to use A-AS instead of H-AS. The attack now proceeds
exactly as in Steps 3ff. of the attack description above. exactly as in Steps 3ff. of the attack description above.
o *Implicit Grant*: In the implicit grant, the attacker receives an * *Implicit Grant*: In the implicit grant, the attacker receives an
access token instead of the code; the rest of the attack works as access token instead of the code; the rest of the attack works as
above. above.
o *Per-AS Redirect URIs*: If clients use different redirect URIs for * *Per-AS Redirect URIs*: If clients use different redirect URIs for
different ASs, do not store the selected AS in the user's session, different ASs, do not store the selected AS in the user's session,
and ASs do not check the redirect URIs properly, attackers can and ASs do not check the redirect URIs properly, attackers can
mount an attack called "Cross-Social Network Request Forgery". mount an attack called "Cross-Social Network Request Forgery".
These attacks have been observed in practice. Refer to These attacks have been observed in practice. Refer to
[oauth_security_jcs_14] for details. [oauth_security_jcs_14] for details.
o *OpenID Connect*: There are variants that can be used to attack * *OpenID Connect*: There are variants that can be used to attack
OpenID Connect. In these attacks, the attacker misuses features OpenID Connect. In these attacks, the attacker misuses features
of the OpenID Connect Discovery mechanism or replays access tokens of the OpenID Connect Discovery mechanism or replays access tokens
or ID Tokens to conduct a Mix-Up Attack. The attacks are or ID Tokens to conduct a Mix-Up Attack. The attacks are
described in detail in [arXiv.1704.08539], Appendix A, and described in detail in [arXiv.1704.08539], Appendix A, and
[arXiv.1508.04324v2], Section 6 ("Malicious Endpoints Attacks"). [arXiv.1508.04324v2], Section 6 ("Malicious Endpoints Attacks").
4.4.2. Countermeasures 4.4.2. Countermeasures
In scenarios where an OAuth client interacts with multiple In scenarios where an OAuth client interacts with multiple
authorization servers, clients MUST prevent mix-up attacks. authorization servers, clients MUST prevent mix-up attacks.
skipping to change at page 20, line 41 skipping to change at page 20, line 41
Unfortunately, distinct redirect URIs per AS do not work for all Unfortunately, distinct redirect URIs per AS do not work for all
kinds of OAuth clients. They are effective for web and JavaScript kinds of OAuth clients. They are effective for web and JavaScript
apps and for native apps with claimed URLs. Attacks on native apps apps and for native apps with claimed URLs. Attacks on native apps
using custom schemes or redirect URIs on localhost cannot be using custom schemes or redirect URIs on localhost cannot be
prevented this way. prevented this way.
If clients cannot use distinct redirect URIs for each AS, the If clients cannot use distinct redirect URIs for each AS, the
following options exist: following options exist:
o Authorization servers can be configured to return an AS * Authorization servers can be configured to return an AS
identitifier ("iss") as a non-standard parameter in the identitifier ("iss") as a non-standard parameter in the
authorization response. This enables complying clients to compare authorization response. This enables complying clients to compare
this data to the "iss" identifier of the AS it believed it sent this data to the "iss" identifier of the AS it believed it sent
the user agent to. the user agent to.
o In OpenID Connect, if an ID Token is returned in the authorization * In OpenID Connect, if an ID Token is returned in the authorization
response, it carries client ID and issuer. It can be used in the response, it carries client ID and issuer. It can be used in the
same way as the "iss" parameter. same way as the "iss" parameter.
4.5. Authorization Code Injection 4.5. Authorization Code Injection
In an authorization code injection attack, the attacker attempts to In an authorization code injection attack, the attacker attempts to
inject a stolen authorization code into the attacker's own session inject a stolen authorization code into the attacker's own session
with the client. The aim is to associate the attacker's session at with the client. The aim is to associate the attacker's session at
the client with the victim's resources or identity. the client with the victim's resources or identity.
This attack is useful if the attacker cannot exchange the This attack is useful if the attacker cannot exchange the
authorization code for an access token himself. Examples include: authorization code for an access token himself. Examples include:
o The code is bound to a particular confidential client and the * The code is bound to a particular confidential client and the
attacker is unable to obtain the required client credentials to attacker is unable to obtain the required client credentials to
redeem the code himself. redeem the code himself.
o The attacker wants to access certain functions in this particular * The attacker wants to access certain functions in this particular
client. As an example, the attacker wants to impersonate his client. As an example, the attacker wants to impersonate his
victim in a certain app or on a certain web site. victim in a certain app or on a certain web site.
o The authorization or resource servers are limited to certain * The authorization or resource servers are limited to certain
networks that the attacker is unable to access directly. networks that the attacker is unable to access directly.
In the following attack description and discussion, we assume the In the following attack description and discussion, we assume the
presence of a web (A1) or network attacker (A2). presence of a web (A1) or network attacker (A2).
4.5.1. Attack Description 4.5.1. Attack Description
The attack works as follows: The attack works as follows:
1. The attacker obtains an authorization code by performing any of 1. The attacker obtains an authorization code by performing any of
skipping to change at page 22, line 40 skipping to change at page 22, line 40
authorization requests. But this URI would not match the tampered authorization requests. But this URI would not match the tampered
redirect URI used by the attacker (otherwise, the redirect would not redirect URI used by the attacker (otherwise, the redirect would not
land at the attackers page). So the authorization server would land at the attackers page). So the authorization server would
detect the attack and refuse to exchange the code. detect the attack and refuse to exchange the code.
Note: this check could also detect attempts to inject an Note: this check could also detect attempts to inject an
authorization code which had been obtained from another instance of authorization code which had been obtained from another instance of
the same client on another device, if certain conditions are the same client on another device, if certain conditions are
fulfilled: fulfilled:
o the redirect URI itself needs to contain a nonce or another kind * the redirect URI itself needs to contain a nonce or another kind
of one-time use, secret data and of one-time use, secret data and
o the client has bound this data to this particular instance of the * the client has bound this data to this particular instance of the
client. client.
But this approach conflicts with the idea to enforce exact redirect But this approach conflicts with the idea to enforce exact redirect
URI matching at the authorization endpoint. Moreover, it has been URI matching at the authorization endpoint. Moreover, it has been
observed that providers very often ignore the "redirect_uri" check observed that providers very often ignore the "redirect_uri" check
requirement at this stage, maybe because it doesn't seem to be requirement at this stage, maybe because it doesn't seem to be
security-critical from reading the specification. security-critical from reading the specification.
Other providers just pattern match the "redirect_uri" parameter Other providers just pattern match the "redirect_uri" parameter
against the registered redirect URI pattern. This saves the against the registered redirect URI pattern. This saves the
skipping to change at page 23, line 30 skipping to change at page 23, line 30
This document therefore recommends to instead bind every This document therefore recommends to instead bind every
authorization code to a certain client instance on a certain device authorization code to a certain client instance on a certain device
(or in a certain user agent) in the context of a certain transaction (or in a certain user agent) in the context of a certain transaction
using one of the mechanisms described next. using one of the mechanisms described next.
4.5.3. Countermeasures 4.5.3. Countermeasures
There are two good technical solutions to achieve this goal: There are two good technical solutions to achieve this goal:
o *PKCE*: The PKCE parameter "code_challenge" along with the * *PKCE*: The PKCE parameter "code_challenge" along with the
corresponding "code_verifier" as specified in [RFC7636] can be corresponding "code_verifier" as specified in [RFC7636] can be
used as a countermeasure. In contrast to its original intention, used as a countermeasure. In contrast to its original intention,
the verifier check fails although the client uses its correct the verifier check fails although the client uses its correct
verifier but the code is associated with a challenge that does not verifier but the code is associated with a challenge that does not
match. PKCE is a deployed OAuth feature, although its original match. PKCE is a deployed OAuth feature, although its original
intended use was solely focused on securing native apps, not the intended use was solely focused on securing native apps, not the
broader use recommended by this document. broader use recommended by this document.
o *Nonce*: OpenID Connect's existing "nonce" parameter can be used * *Nonce*: OpenID Connect's existing "nonce" parameter can be used
for the same purpose. The "nonce" value is one-time use and for the same purpose. The "nonce" value is one-time use and
created by the client. The client is supposed to bind it to the created by the client. The client is supposed to bind it to the
user agent session and sends it with the initial request to the user agent session and sends it with the initial request to the
OpenID Provider (OP). The OP binds "nonce" to the authorization OpenID Provider (OP). The OP binds "nonce" to the authorization
code and attests this binding in the ID Token, which is issued as code and attests this binding in the ID Token, which is issued as
part of the code exchange at the token endpoint. If an attacker part of the code exchange at the token endpoint. If an attacker
injected an authorization code in the authorization response, the injected an authorization code in the authorization response, the
nonce value in the client session and the nonce value in the ID nonce value in the client session and the nonce value in the ID
token will not match and the attack is detected. The assumption token will not match and the attack is detected. The assumption
is that an attacker cannot get hold of the user agent state on the is that an attacker cannot get hold of the user agent state on the
skipping to change at page 25, line 33 skipping to change at page 25, line 33
4.7.1. Countermeasures 4.7.1. Countermeasures
The traditional countermeasure are CSRF tokens that are bound to the The traditional countermeasure are CSRF tokens that are bound to the
user agent and passed in the "state" parameter to the authorization user agent and passed in the "state" parameter to the authorization
server as described in [RFC6819]. The same protection is provided by server as described in [RFC6819]. The same protection is provided by
PKCE or the OpenID Connect "nonce" value. PKCE or the OpenID Connect "nonce" value.
When using PKCE instead of "state" or "nonce" for CSRF protection, it When using PKCE instead of "state" or "nonce" for CSRF protection, it
is important to note that: is important to note that:
o Clients MUST ensure that the AS supports PKCE before using PKCE * Clients MUST ensure that the AS supports PKCE before using PKCE
for CSRF protection. If an authorization server does not support for CSRF protection. If an authorization server does not support
PKCE, "state" or "nonce" MUST be used for CSRF protection. PKCE, "state" or "nonce" MUST be used for CSRF protection.
o If "state" is used for carrying application state, and integrity * If "state" is used for carrying application state, and integrity
of its contents is a concern, clients MUST protect "state" against of its contents is a concern, clients MUST protect "state" against
tampering and swapping. This can be achieved by binding the tampering and swapping. This can be achieved by binding the
contents of state to the browser session and/or signed/encrypted contents of state to the browser session and/or signed/encrypted
state values [I-D.bradley-oauth-jwt-encoded-state]. state values [I-D.bradley-oauth-jwt-encoded-state].
AS therefore MUST provide a way to detect their support for PKCE AS therefore MUST provide a way to detect their support for PKCE
either via AS metadata according to [RFC8414] or provide a either via AS metadata according to [RFC8414] or provide a
deployment-specific way to ensure or determine PKCE support. deployment-specific way to ensure or determine PKCE support.
4.8. Access Token Leakage at the Resource Server 4.8. Access Token Leakage at the Resource Server
skipping to change at page 28, line 20 skipping to change at page 28, line 19
3. The RS must implement the actual proof of possession check. This 3. The RS must implement the actual proof of possession check. This
is typically done on the application level, often tied to is typically done on the application level, often tied to
specific material provided by transport layer (e.g., TLS). The specific material provided by transport layer (e.g., TLS). The
RS must also ensure that replay of the proof of possession is not RS must also ensure that replay of the proof of possession is not
possible. possible.
There exist several proposals to demonstrate the proof of possession There exist several proposals to demonstrate the proof of possession
in the scope of the OAuth working group: in the scope of the OAuth working group:
o *OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound * *OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound
Access Tokens* ([RFC8705]): The approach as specified in this Access Tokens* ([RFC8705]): The approach as specified in this
document allows the use of mutual TLS (mTLS) for both client document allows the use of mutual TLS (mTLS) for both client
authentication and sender-constrained access tokens. For the authentication and sender-constrained access tokens. For the
purpose of sender-constrained access tokens, the client is purpose of sender-constrained access tokens, the client is
identified towards the resource server by the fingerprint of its identified towards the resource server by the fingerprint of its
public key. During processing of an access token request, the public key. During processing of an access token request, the
authorization server obtains the client's public key from the TLS authorization server obtains the client's public key from the TLS
stack and associates its fingerprint with the respective access stack and associates its fingerprint with the respective access
tokens. The resource server in the same way obtains the public tokens. The resource server in the same way obtains the public
key from the TLS stack and compares its fingerprint with the key from the TLS stack and compares its fingerprint with the
fingerprint associated with the access token. fingerprint associated with the access token.
o *DPoP* ([I-D.fett-oauth-dpop]): DPoP (Demonstration of Proof-of- * *DPoP* ([I-D.ietf-oauth-dpop]): DPoP (Demonstration of Proof-of-
Possession at the Application Layer) outlines an application-level Possession at the Application Layer) outlines an application-level
sender-constraining for access and refresh tokens that can be used sender-constraining for access and refresh tokens that can be used
in cases where neither mTLS nor OAuth Token Binding (see below) in cases where neither mTLS nor OAuth Token Binding (see below)
are available. It uses proof-of-possession based on a public/ are available. It uses proof-of-possession based on a public/
private key pair and application-level signing. DPoP can be used private key pair and application-level signing. DPoP can be used
with public clients and, in case of confidential clients, can be with public clients and, in case of confidential clients, can be
combined with any client authentication method. combined with any client authentication method.
o *OAuth Token Binding* ([I-D.ietf-oauth-token-binding]): In this * *OAuth Token Binding* ([I-D.ietf-oauth-token-binding]): In this
approach, an access token is, via the token binding ID, bound to approach, an access token is, via the token binding ID, bound to
key material representing a long term association between a client key material representing a long term association between a client
and a certain TLS host. Negotiation of the key material and proof and a certain TLS host. Negotiation of the key material and proof
of possession in the context of a TLS handshake is taken care of of possession in the context of a TLS handshake is taken care of
by the TLS stack. The client needs to determine the token binding by the TLS stack. The client needs to determine the token binding
ID of the target resource server and pass this data to the access ID of the target resource server and pass this data to the access
token request. The authorization server then associates the token request. The authorization server then associates the
access token with this ID. The resource server checks on every access token with this ID. The resource server checks on every
invocation that the token binding ID of the active TLS connection invocation that the token binding ID of the active TLS connection
and the token binding ID of associated with the access token and the token binding ID of associated with the access token
match. Since all crypto-related functions are covered by the TLS match. Since all crypto-related functions are covered by the TLS
stack, this approach is very client developer friendly. As a stack, this approach is very client developer friendly. As a
prerequisite, token binding as described in [RFC8473] (including prerequisite, token binding as described in [RFC8473] (including
federated token bindings) must be supported on all ends (client, federated token bindings) must be supported on all ends (client,
authorization server, resource server). authorization server, resource server).
o *Signed HTTP Requests* ([I-D.ietf-oauth-signed-http-request]): * *Signed HTTP Requests* ([I-D.ietf-oauth-signed-http-request]):
This approach utilizes [I-D.ietf-oauth-pop-key-distribution] and This approach utilizes [I-D.ietf-oauth-pop-key-distribution] and
represents the elements of the signature in a JSON object. The represents the elements of the signature in a JSON object. The
signature is built using JWS. The mechanism has built-in support signature is built using JWS. The mechanism has built-in support
for signing of HTTP method, query parameters and headers. It also for signing of HTTP method, query parameters and headers. It also
incorporates a timestamp as basis for replay prevention. incorporates a timestamp as basis for replay prevention.
o *JWT Pop Tokens* ([I-D.sakimura-oauth-jpop]): This draft describes * *JWT Pop Tokens* ([I-D.sakimura-oauth-jpop]): This draft describes
different ways to constrain access token usage, namely TLS or different ways to constrain access token usage, namely TLS or
request signing. Note: Since the authors of this draft request signing. Note: Since the authors of this draft
contributed the TLS-related proposal to [RFC8705], this document contributed the TLS-related proposal to [RFC8705], this document
only considers the request signing part. For request signing, the only considers the request signing part. For request signing, the
draft utilizes [I-D.ietf-oauth-pop-key-distribution] and draft utilizes [I-D.ietf-oauth-pop-key-distribution] and
[RFC7800]. The signature data is represented in a JWT and JWS is [RFC7800]. The signature data is represented in a JWT and JWS is
used for signing. Replay prevention is provided by building the used for signing. Replay prevention is provided by building the
signature over a server-provided nonce, client-provided nonce and signature over a server-provided nonce, client-provided nonce and
a nonce counter. a nonce counter.
skipping to change at page 31, line 26 skipping to change at page 31, line 26
to access other resource servers. to access other resource servers.
Preventing server breaches by hardening and monitoring server systems Preventing server breaches by hardening and monitoring server systems
is considered a standard operational procedure and, therefore, out of is considered a standard operational procedure and, therefore, out of
the scope of this document. This section focuses on the impact of the scope of this document. This section focuses on the impact of
OAuth-related breaches and the replaying of captured access tokens. OAuth-related breaches and the replaying of captured access tokens.
The following measures should be taken into account by implementers The following measures should be taken into account by implementers
in order to cope with access token replay by malicious actors: in order to cope with access token replay by malicious actors:
o Sender-constrained access tokens as described in Section 4.8.1.1.2 * Sender-constrained access tokens as described in Section 4.8.1.1.2
SHOULD be used to prevent the attacker from replaying the access SHOULD be used to prevent the attacker from replaying the access
tokens on other resource servers. Depending on the severity of tokens on other resource servers. Depending on the severity of
the penetration, sender-constrained access tokens will also the penetration, sender-constrained access tokens will also
prevent replay on the compromised system. prevent replay on the compromised system.
o Audience restriction as described in Section 4.8.1.1.3 SHOULD be * Audience restriction as described in Section 4.8.1.1.3 SHOULD be
used to prevent replay of captured access tokens on other resource used to prevent replay of captured access tokens on other resource
servers. servers.
o The resource server MUST treat access tokens like any other * The resource server MUST treat access tokens like any other
credentials. It is considered good practice to not log them and credentials. It is considered good practice to not log them and
not store them in plain text. not store them in plain text.
The first and second recommendation also apply to other scenarios The first and second recommendation also apply to other scenarios
where access tokens leak (see Attacker A5). where access tokens leak (see Attacker A5).
4.9. Open Redirection 4.9. Open Redirection
The following attacks can occur when an AS or client has an open The following attacks can occur when an AS or client has an open
redirector. An open redirector is an endpoint that forwards a user's redirector. An open redirector is an endpoint that forwards a user's
skipping to change at page 34, line 41 skipping to change at page 34, line 41
4.12.1. Discussion 4.12.1. Discussion
Refresh tokens are an attractive target for attackers since they Refresh tokens are an attractive target for attackers since they
represent the overall grant a resource owner delegated to a certain represent the overall grant a resource owner delegated to a certain
client. If an attacker is able to exfiltrate and successfully replay client. If an attacker is able to exfiltrate and successfully replay
a refresh token, the attacker will be able to mint access tokens and a refresh token, the attacker will be able to mint access tokens and
use them to access resource servers on behalf of the resource owner. use them to access resource servers on behalf of the resource owner.
[RFC6749] already provides a robust baseline protection by requiring [RFC6749] already provides a robust baseline protection by requiring
o confidentiality of the refresh tokens in transit and storage, * confidentiality of the refresh tokens in transit and storage,
o the transmission of refresh tokens over TLS-protected connections * the transmission of refresh tokens over TLS-protected connections
between authorization server and client, between authorization server and client,
o the authorization server to maintain and check the binding of a * the authorization server to maintain and check the binding of a
refresh token to a certain client (i.e., "client_id"), refresh token to a certain client (i.e., "client_id"),
o authentication of this client during token refresh, if possible, * authentication of this client during token refresh, if possible,
and and
o that refresh tokens cannot be generated, modified, or guessed. * that refresh tokens cannot be generated, modified, or guessed.
[RFC6749] also lays the foundation for further (implementation [RFC6749] also lays the foundation for further (implementation
specific) security measures, such as refresh token expiration and specific) security measures, such as refresh token expiration and
revocation as well as refresh token rotation by defining respective revocation as well as refresh token rotation by defining respective
error codes and response behavior. error codes and response behavior.
This specification gives recommendations beyond the scope of This specification gives recommendations beyond the scope of
[RFC6749] and clarifications. [RFC6749] and clarifications.
4.12.2. Recommendations 4.12.2. Recommendations
skipping to change at page 35, line 33 skipping to change at page 35, line 33
experience. experience.
If refresh tokens are issued, those refresh tokens MUST be bound to If refresh tokens are issued, those refresh tokens MUST be bound to
the scope and resource servers as consented by the resource owner. the scope and resource servers as consented by the resource owner.
This is to prevent privilege escalation by the legitimate client and This is to prevent privilege escalation by the legitimate client and
reduce the impact of refresh token leakage. reduce the impact of refresh token leakage.
Authorization server MUST utilize one of these methods to detect Authorization server MUST utilize one of these methods to detect
refresh token replay by malicious actors for public clients: refresh token replay by malicious actors for public clients:
o *Sender-constrained refresh tokens:* the authorization server * *Sender-constrained refresh tokens:* the authorization server
cryptographically binds the refresh token to a certain client cryptographically binds the refresh token to a certain client
instance by utilizing [I-D.ietf-oauth-token-binding] or [RFC8705]. instance by utilizing [I-D.ietf-oauth-token-binding] or [RFC8705].
o *Refresh token rotation:* the authorization server issues a new * *Refresh token rotation:* the authorization server issues a new
refresh token with every access token refresh response. The refresh token with every access token refresh response. The
previous refresh token is invalidated but information about the previous refresh token is invalidated but information about the
relationship is retained by the authorization server. If a relationship is retained by the authorization server. If a
refresh token is compromised and subsequently used by both the refresh token is compromised and subsequently used by both the
attacker and the legitimate client, one of them will present an attacker and the legitimate client, one of them will present an
invalidated refresh token, which will inform the authorization invalidated refresh token, which will inform the authorization
server of the breach. The authorization server cannot determine server of the breach. The authorization server cannot determine
which party submitted the invalid refresh token, but it will which party submitted the invalid refresh token, but it will
revoke the active refresh token. This stops the attack at the revoke the active refresh token. This stops the attack at the
cost of forcing the legitimate client to obtain a fresh cost of forcing the legitimate client to obtain a fresh
skipping to change at page 36, line 11 skipping to change at page 36, line 12
may be encoded into the refresh token itself. This can enable an may be encoded into the refresh token itself. This can enable an
authorization server to efficiently determine the grant to which a authorization server to efficiently determine the grant to which a
refresh token belongs, and by extension, all refresh tokens that refresh token belongs, and by extension, all refresh tokens that
need to be revoked. Authorization servers MUST ensure the need to be revoked. Authorization servers MUST ensure the
integrity of the refresh token value in this case, for example, integrity of the refresh token value in this case, for example,
using signatures. using signatures.
Authorization servers MAY revoke refresh tokens automatically in case Authorization servers MAY revoke refresh tokens automatically in case
of a security event, such as: of a security event, such as:
o password change * password change
o logout at the authorization server * logout at the authorization server
Refresh tokens SHOULD expire if the client has been inactive for some Refresh tokens SHOULD expire if the client has been inactive for some
time, i.e., the refresh token has not been used to obtain fresh time, i.e., the refresh token has not been used to obtain fresh
access tokens for some time. The expiration time is at the access tokens for some time. The expiration time is at the
discretion of the authorization server. It might be a global value discretion of the authorization server. It might be a global value
or determined based on the client policy or the grant associated with or determined based on the client policy or the grant associated with
the refresh token (and its sensitivity). the refresh token (and its sensitivity).
4.13. Client Impersonating Resource Owner 4.13. Client Impersonating Resource Owner
skipping to change at page 37, line 49 skipping to change at page 37, line 49
by the authorization server. Even in such cases, additional by the authorization server. Even in such cases, additional
countermeasures SHOULD still be employed. countermeasures SHOULD still be employed.
5. Acknowledgements 5. Acknowledgements
We would like to thank Jim Manico, Phil Hunt, Nat Sakimura, Christian We would like to thank Jim Manico, Phil Hunt, Nat Sakimura, Christian
Mainka, Doug McDorman, Johan Peeters, Joseph Heenan, Brock Allen, Mainka, Doug McDorman, Johan Peeters, Joseph Heenan, Brock Allen,
Vittorio Bertocci, David Waite, Nov Matake, Tomek Stojecki, Dominick Vittorio Bertocci, David Waite, Nov Matake, Tomek Stojecki, Dominick
Baier, Neil Madden, William Dennis, Dick Hardt, Petteri Stenius, Baier, Neil Madden, William Dennis, Dick Hardt, Petteri Stenius,
Annabelle Richard Backman, Aaron Parecki, George Fletscher, Brian Annabelle Richard Backman, Aaron Parecki, George Fletscher, Brian
Campbell, Konstantin Lapine, Tim Wuertele, Guido Schmitz, Hans Campbell, Konstantin Lapine, Tim Würtele, Guido Schmitz, Hans
Zandbelt, Jared Jennings, Michael Peck, Pedram Hosseyni, Michael B. Zandbelt, Jared Jennings, Michael Peck, Pedram Hosseyni, Michael B.
Jones, and Travis Spencer for their valuable feedback. Jones, and Travis Spencer for their valuable feedback.
6. IANA Considerations 6. IANA Considerations
This draft includes no request to IANA. This draft includes no request to IANA.
7. Security Considerations 7. Security Considerations
All relevant security considerations have been given in the All relevant security considerations have been given in the
functional specification. functional specification.
8. References 8. Normative References
8.1. Normative References
[oauth-v2-form-post-response-mode]
Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response
Mode", April 2015, <http://openid.net/specs/oauth-v2-form-
post-response-mode-1_0.html>.
[OpenID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T.
C. Mortimore, "OpenID Connect Core 1.0 incorporating Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
errata set 1", Nov 2014, and Certificate-Bound Access Tokens", February 2020,
<http://openid.net/specs/openid-connect-core-1_0.html>. <https://www.rfc-editor.org/info/rfc8705>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>.
[oauth-v2-form-post-response-mode]
Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response
Mode", 27 April 2015, <http://openid.net/specs/oauth-v2-
form-post-response-mode-1_0.html>.
[OpenID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 1", 8 November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
for Code Exchange by OAuth Public Clients", RFC 7636,
DOI 10.17487/RFC7636, September 2015,
<https://www.rfc-editor.org/info/rfc7636>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012, DOI 10.17487/RFC6750, October 2012,
<https://www.rfc-editor.org/info/rfc6750>. <https://www.rfc-editor.org/info/rfc6750>.
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819, Threat Model and Security Considerations", RFC 6819,
DOI 10.17487/RFC6819, January 2013, DOI 10.17487/RFC6819, January 2013,
<https://www.rfc-editor.org/info/rfc6819>. <https://www.rfc-editor.org/info/rfc6819>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key 9. Informative References
for Code Exchange by OAuth Public Clients", RFC 7636,
DOI 10.17487/RFC7636, September 2015,
<https://www.rfc-editor.org/info/rfc7636>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 [owasp_redir]
Authorization Server Metadata", RFC 8414, "OWASP Cheat Sheet Series - Unvalidated Redirects and
DOI 10.17487/RFC8414, June 2018, Forwards",
<https://www.rfc-editor.org/info/rfc8414>. <https://cheatsheetseries.owasp.org/cheatsheets/
Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html>.
[RFC8418] Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Agreement Algorithm with X25519 and X448 in the Requirement Levels", BCP 14, RFC 2119,
Cryptographic Message Syntax (CMS)", RFC 8418, DOI 10.17487/RFC2119, March 1997,
DOI 10.17487/RFC8418, August 2018, <https://www.rfc-editor.org/info/rfc2119>.
<https://www.rfc-editor.org/info/rfc8418>.
[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. [oauth_security_ubc]
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication Sun, S.-T. and K. Beznosov, "The Devil is in the
and Certificate-Bound Access Tokens", February 2020, (Implementation) Details: An Empirical Analysis of OAuth
<https://www.rfc-editor.org/info/rfc8705>. SSO Systems", October 2012,
<http://passwordresearch.com/papers/paper267.html>.
8.2. Informative References [I-D.ietf-oauth-signed-http-request]
Richer, J., Bradley, J., and H. Tschofenig, "A Method for
Signing HTTP Requests for OAuth", Work in Progress,
Internet-Draft, draft-ietf-oauth-signed-http-request-03, 8
August 2016, <https://tools.ietf.org/html/draft-ietf-
oauth-signed-http-request-03>.
[arXiv.1508.04324v2] [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Mladenov, V., Mainka, C., and J. Schwenk, "On the security Possession Key Semantics for JSON Web Tokens (JWTs)",
of modern Single Sign-On Protocols: Second-Order RFC 7800, DOI 10.17487/RFC7800, April 2016,
Vulnerabilities in OpenID Connect", January 2016, <https://www.rfc-editor.org/info/rfc7800>.
<http://arxiv.org/abs/1508.04324v2/>.
[arXiv.1601.01229] [subdomaintakeover]
Fett, D., Kuesters, R., and G. Schmitz, "A Comprehensive Liu, D., Hao, S., and H. Wang, "All Your DNS Records Point
Formal Security Analysis of OAuth 2.0", January 2016, to Us: Understanding the Security Threats of Dangling DNS
<http://arxiv.org/abs/1601.01229/>. Records", 24 October 2016,
<https://www.eecis.udel.edu/~hnw/paper/ccs16a.pdf>.
[arXiv.1704.08539] [arXiv.1704.08539]
Fett, D., Kuesters, R., and G. Schmitz, "The Web SSO Fett, D., Küsters, R., and G. Schmitz, "The Web SSO
Standard OpenID Connect: In-Depth Formal Security Analysis Standard OpenID Connect: In-Depth Formal Security Analysis
and Security Guidelines", April 2017, and Security Guidelines", 27 April 2017,
<http://arxiv.org/abs/1704.08539/>. <http://arxiv.org/abs/1704.08539/>.
[arXiv.1901.11520] [I-D.ietf-oauth-resource-indicators]
Fett, D., Hosseyni, P., and R. Kuesters, "An Extensive Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Formal Security Analysis of the OpenID Financial-grade Indicators for OAuth 2.0", Work in Progress, Internet-
API", January 2019, <http://arxiv.org/abs/1901.11520/>. Draft, draft-ietf-oauth-resource-indicators-08, 11
September 2019, <https://tools.ietf.org/html/draft-ietf-
oauth-resource-indicators-08>.
[bug.chromium] [arXiv.1601.01229]
"Referer header includes URL fragment when opening link Fett, D., Küsters, R., and G. Schmitz, "A Comprehensive
using New Tab", Formal Security Analysis of OAuth 2.0", 6 January 2016,
<https://bugs.chromium.org/p/chromium/issues/ <http://arxiv.org/abs/1601.01229/>.
detail?id=168213/>.
[CSP-2] West, M., Barth, A., and D. Veditz, "Content Security [arXiv.1901.11520]
Policy Level 2", July 2015, <https://www.w3.org/TR/CSP2>. Fett, D., Hosseyni, P., and R. Küsters, "An Extensive
Formal Security Analysis of the OpenID Financial-grade
API", 31 January 2019, <http://arxiv.org/abs/1901.11520/>.
[I-D.bradley-oauth-jwt-encoded-state] [I-D.bradley-oauth-jwt-encoded-state]
Bradley, J., Lodderstedt, T., and H. Zandbelt, "Encoding Bradley, J., Lodderstedt, T., and H. Zandbelt, "Encoding
claims in the OAuth 2 state parameter using a JWT", draft- claims in the OAuth 2 state parameter using a JWT", Work
bradley-oauth-jwt-encoded-state-09 (work in progress), in Progress, Internet-Draft, draft-bradley-oauth-jwt-
November 2018. encoded-state-09, 4 November 2018,
<https://tools.ietf.org/html/draft-bradley-oauth-jwt-
encoded-state-09>.
[I-D.fett-oauth-dpop] [I-D.ietf-oauth-token-binding]
Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., Campbell, B., Bradley, J., and W. Denniss,
Jones, M., and D. Waite, "OAuth 2.0 Demonstration of "OAuth 2.0 Token Binding", Work in Progress, Internet-
Proof-of-Possession at the Application Layer (DPoP)", Draft, draft-ietf-oauth-token-binding-08, 19 October 2018,
draft-fett-oauth-dpop-03 (work in progress), October 2019. <https://tools.ietf.org/html/draft-ietf-oauth-token-
binding-08>.
[I-D.ietf-oauth-jwsreq] [I-D.ietf-oauth-jwsreq]
Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization
Framework: JWT Secured Authorization Request (JAR)", Framework: JWT Secured Authorization Request (JAR)", Work
draft-ietf-oauth-jwsreq-20 (work in progress), October in Progress, Internet-Draft, draft-ietf-oauth-jwsreq-20,
2019. 21 October 2019,
<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20>.
[I-D.ietf-oauth-par] [I-D.ietf-oauth-dpop]
Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", Jones, M., and D. Waite, "OAuth 2.0 Demonstration of
draft-ietf-oauth-par-00 (work in progress), December 2019. Proof-of-Possession at the Application Layer (DPoP)", Work
in Progress, Internet-Draft, draft-ietf-oauth-dpop-00, 1
April 2020,
<https://tools.ietf.org/html/draft-ietf-oauth-dpop-00>.
[I-D.ietf-oauth-pop-key-distribution] [I-D.ietf-oauth-pop-key-distribution]
Bradley, J., Hunt, P., Jones, M., Tschofenig, H., and M. Bradley, J., Hunt, P., Jones, M., Tschofenig, H., and M.
Meszaros, "OAuth 2.0 Proof-of-Possession: Authorization Meszaros, "OAuth 2.0 Proof-of-Possession: Authorization
Server to Client Key Distribution", draft-ietf-oauth-pop- Server to Client Key Distribution", Work in Progress,
key-distribution-07 (work in progress), March 2019. Internet-Draft, draft-ietf-oauth-pop-key-distribution-07,
27 March 2019, <https://tools.ietf.org/html/draft-ietf-
oauth-pop-key-distribution-07>.
[I-D.ietf-oauth-rar] [CSP-2] West, M., Barth, A., and D. Veditz, "Content Security
Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Policy Level 2", July 2015, <https://www.w3.org/TR/CSP2>.
Rich Authorization Requests", draft-ietf-oauth-rar-00
(work in progress), January 2020.
[I-D.ietf-oauth-resource-indicators] [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
Campbell, B., Bradley, J., and H. Tschofenig, "Resource P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
Indicators for OAuth 2.0", draft-ietf-oauth-resource- RFC 7591, DOI 10.17487/RFC7591, July 2015,
indicators-08 (work in progress), September 2019. <https://www.rfc-editor.org/info/rfc7591>.
[I-D.ietf-oauth-signed-http-request] [webcrypto]
Richer, J., Bradley, J., and H. Tschofenig, "A Method for Watson, M., "Web Cryptography API", 26 January 2017,
Signing HTTP Requests for OAuth", draft-ietf-oauth-signed- <https://www.w3.org/TR/2017/REC-WebCryptoAPI-20170126/>.
http-request-03 (work in progress), August 2016.
[I-D.ietf-oauth-token-binding] [webauthn] Balfanz, D., Czeskis, A., Hodges, J., Jones, J.C., Jones,
Jones, M., Campbell, B., Bradley, J., and W. Denniss, M.B., Kumar, A., Liao, A., Lindemann, R., and E. Lundberg,
"OAuth 2.0 Token Binding", draft-ietf-oauth-token- "Web Authentication: An API for accessing Public Key
binding-08 (work in progress), October 2018. Credentials Level 1", 4 March 2019,
<https://www.w3.org/TR/2019/REC-webauthn-1-20190304/>.
[I-D.sakimura-oauth-jpop] [webappsec-referrer-policy]
Sakimura, N., Li, K., and J. Bradley, "The OAuth 2.0 Eisinger, J. and E. Stark, "Referrer Policy", 20 April
Authorization Framework: JWT Pop Token Usage", draft- 2017, <https://w3c.github.io/webappsec-referrer-policy>.
sakimura-oauth-jpop-05 (work in progress), July 2019.
[I-D.ietf-oauth-rar]
Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", Work in Progress, Internet-
Draft, draft-ietf-oauth-rar-01, 19 February 2020,
<https://tools.ietf.org/html/draft-ietf-oauth-rar-01>.
[I-D.ietf-oauth-par]
Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
Work in Progress, Internet-Draft, draft-ietf-oauth-par-01,
18 February 2020,
<https://tools.ietf.org/html/draft-ietf-oauth-par-01>.
[arXiv.1508.04324v2]
Mladenov, V., Mainka, C., and J. Schwenk, "On the security
of modern Single Sign-On Protocols: Second-Order
Vulnerabilities in OpenID Connect", 7 January 2016,
<http://arxiv.org/abs/1508.04324v2/>.
[oauth_security_cmu] [oauth_security_cmu]
Chen, E., Pei, Y., Chen, S., Tian, Y., Kotcher, R., and P. Chen, E., Pei, Y., Chen, S., Tian, Y., Kotcher, R., and P.
Tague, "OAuth Demystified for Mobile Application Tague, "OAuth Demystified for Mobile Application
Developers", November 2014, Developers", November 2014,
<http://css.csail.mit.edu/6.858/2012/readings/oauth- <http://css.csail.mit.edu/6.858/2012/readings/oauth-
sso.pdf>. sso.pdf>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[bug.chromium]
"Referer header includes URL fragment when opening link
using New Tab",
<https://bugs.chromium.org/p/chromium/issues/
detail?id=168213/>.
[oauth_security_jcs_14] [oauth_security_jcs_14]
Bansal, C., Bhargavan, K., Delignat-Lavaud, A., and S. Bansal, C., Bhargavan, K., Delignat-Lavaud, A., and S.
Maffeis, "Discovering concrete attacks on website Maffeis, "Discovering concrete attacks on website
authorization by formal analysis", April 2014, authorization by formal analysis", 23 April 2014,
<https://www.doc.ic.ac.uk/~maffeis/papers/jcs14.pdf>. <https://www.doc.ic.ac.uk/~maffeis/papers/jcs14.pdf>.
[oauth_security_ubc]
Sun, S. and K. Beznosov, "The Devil is in the
(Implementation) Details: An Empirical Analysis of OAuth
SSO Systems", October 2012,
<http://passwordresearch.com/papers/paper267.html>.
[owasp_redir]
"OWASP Cheat Sheet Series - Unvalidated Redirects and
Forwards",
<https://cheatsheetseries.owasp.org/cheatsheets/
Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://www.rfc-editor.org/info/rfc7591>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/info/rfc7800>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8473] Popov, A., Nystroem, M., Balfanz, D., Ed., Harper, N., and [RFC8473] Popov, A., Nystroem, M., Balfanz, D., Ed., Harper, N., and
J. Hodges, "Token Binding over HTTP", RFC 8473, J. Hodges, "Token Binding over HTTP", RFC 8473,
DOI 10.17487/RFC8473, October 2018, DOI 10.17487/RFC8473, October 2018,
<https://www.rfc-editor.org/info/rfc8473>. <https://www.rfc-editor.org/info/rfc8473>.
[subdomaintakeover] [I-D.sakimura-oauth-jpop]
Liu, D., Hao, S., and H. Wang, "All Your DNS Records Point Sakimura, N., Li, K., and J. Bradley, "The OAuth 2.0
to Us: Understanding the Security Threats of Dangling DNS Authorization Framework: JWT Pop Token Usage", Work in
Records", October 2016, Progress, Internet-Draft, draft-sakimura-oauth-jpop-05, 22
<https://www.eecis.udel.edu/~hnw/paper/ccs16a.pdf>. July 2019, <https://tools.ietf.org/html/draft-sakimura-
oauth-jpop-05>.
[webappsec-referrer-policy]
Eisinger, J. and E. Stark, "Referrer Policy", April 2017,
<https://w3c.github.io/webappsec-referrer-policy>.
[webauthn]
Balfanz, D., Czeskis, A., Hodges, J., Jones, J., Jones,
M., Kumar, A., Liao, A., Lindemann, R., and E. Lundberg,
"Web Authentication: An API for accessing Public Key
Credentials Level 1", March 2019,
<https://www.w3.org/TR/2019/REC-webauthn-1-20190304/>.
[webcrypto]
Watson, M., "Web Cryptography API", January 2017,
<https://www.w3.org/TR/2017/REC-WebCryptoAPI-20170126/>.
Appendix A. Document History Appendix A. Document History
[[ To be removed from the final specification ]] [[ To be removed from the final specification ]]
-15 -15
o Added info about using CSP to prevent clickjacking * Added info about using CSP to prevent clickjacking
-14 -14
o Changes from WGLC feedback * Changes from WGLC feedback
o Editorial changes * Editorial changes
o AS MUST announce PKCE support either in metadata or using * AS MUST announce PKCE support either in metadata or using
deployment-specific ways (before: SHOULD) deployment-specific ways (before: SHOULD)
-13 -13
o Discourage use of Resource Owner Password Credentials Grant * Discourage use of Resource Owner Password Credentials Grant
o Added text on client impersonating resource owner * Added text on client impersonating resource owner
o Recommend asymmetric methods for client authentication * Recommend asymmetric methods for client authentication
o Encourage use of PKCE mode "S256" * Encourage use of PKCE mode "S256"
o PKCE may replace state for CSRF protection * PKCE may replace state for CSRF protection
o AS SHOULD publish PKCE support * AS SHOULD publish PKCE support
o Cleaned up discussion on auth code injection * Cleaned up discussion on auth code injection
o AS MUST support PKCE * AS MUST support PKCE
-12 -12
o Added updated attacker model * Added updated attacker model
-11 -11
o Adapted section 2.1.2 to outcome of consensus call * Adapted section 2.1.2 to outcome of consensus call
o more text on refresh token inactivity and implementation note on * more text on refresh token inactivity and implementation note on
refresh token replay detection via refresh token rotation refresh token replay detection via refresh token rotation
-10 -10
o incorporated feedback by Joseph Heenan * incorporated feedback by Joseph Heenan
o changed occurrences of SHALL to MUST
o added text on lack of token/cert binding support tokens issued in * changed occurrences of SHALL to MUST
* added text on lack of token/cert binding support tokens issued in
the authorization response as justification to not recommend the authorization response as justification to not recommend
issuing tokens there at all issuing tokens there at all
o added requirement to authenticate clients during code exchange * added requirement to authenticate clients during code exchange
(PKCE or client credential) to 2.1.1. (PKCE or client credential) to 2.1.1.
o added section on refresh tokens * added section on refresh tokens
o editorial enhancements to 2.1.2 based on feedback * editorial enhancements to 2.1.2 based on feedback
-09 -09
o changed text to recommend not to use implicit but code * changed text to recommend not to use implicit but code
o added section on access token injection * added section on access token injection
o reworked sections 3.1 through 3.3 to be more specific on implicit * reworked sections 3.1 through 3.3 to be more specific on implicit
grant issues grant issues
-08 -08
o added recommendations re implicit and token injection * added recommendations re implicit and token injection
o uppercased key words in Section 2 according to RFC 2119 * uppercased key words in Section 2 according to RFC 2119
-07 -07
o incorporated findings of Doug McDorman * incorporated findings of Doug McDorman
o added section on HTTP status codes for redirects * added section on HTTP status codes for redirects
o added new section on access token privilege restriction based on * added new section on access token privilege restriction based on
comments from Johan Peeters comments from Johan Peeters
-06 -06
o reworked section 3.8.1 * reworked section 3.8.1
o incorporated Phil Hunt's feedback * incorporated Phil Hunt's feedback
o reworked section on mix-up * reworked section on mix-up
o extended section on code leakage via referrer header to also cover * extended section on code leakage via referrer header to also cover
state leakage state leakage
o added Daniel Fett as author * added Daniel Fett as author
* replaced text intended to inform WG discussion by recommendations
o replaced text intended to inform WG discussion by recommendations
to implementors to implementors
o modified example URLs to conform to RFC 2606 * modified example URLs to conform to RFC 2606
-05 -05
o Completed sections on code leakage via referrer header, attacks in * Completed sections on code leakage via referrer header, attacks in
browser, mix-up, and CSRF browser, mix-up, and CSRF
o Reworked Code Injection Section * Reworked Code Injection Section
o Added reference to OpenID Connect spec * Added reference to OpenID Connect spec
o removed refresh token leakage as respective considerations have * removed refresh token leakage as respective considerations have
been given in section 10.4 of RFC 6749 been given in section 10.4 of RFC 6749
o first version on open redirection * first version on open redirection
o incorporated Christian Mainka's review feedback * incorporated Christian Mainka's review feedback
-04 -04
o Restructured document for better readability * Restructured document for better readability
o Added best practices on Token Leakage prevention * Added best practices on Token Leakage prevention
-03 -03
o Added section on Access Token Leakage at Resource Server * Added section on Access Token Leakage at Resource Server
o incorporated Brian Campbell's findings * incorporated Brian Campbell's findings
-02 -02
o Folded Mix up and Access Token leakage through a bad AS into new * Folded Mix up and Access Token leakage through a bad AS into new
section for dynamic OAuth threats section for dynamic OAuth threats
o reworked dynamic OAuth section * reworked dynamic OAuth section
-01 -01
o Added references to mitigation methods for token leakage * Added references to mitigation methods for token leakage
o Added reference to Token Binding for Authorization Code
o incorporated feedback of Phil Hunt * Added reference to Token Binding for Authorization Code
o fixed numbering issue in attack descriptions in section 2 * incorporated feedback of Phil Hunt
* fixed numbering issue in attack descriptions in section 2
-00 (WG document) -00 (WG document)
o turned the ID into a WG document and a BCP * turned the ID into a WG document and a BCP
o Added federated app login as topic in Other Topics
* Added federated app login as topic in Other Topics
Authors' Addresses Authors' Addresses
Torsten Lodderstedt Torsten Lodderstedt
yes.com yes.com
Email: torsten@lodderstedt.net Email: torsten@lodderstedt.net
John Bradley John Bradley
Yubico Yubico
 End of changes. 156 change blocks. 
283 lines changed or deleted 296 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/