rfc9700v1.txt   rfc9700.txt 
skipping to change at line 12 skipping to change at line 12
Internet Engineering Task Force (IETF) T. Lodderstedt Internet Engineering Task Force (IETF) T. Lodderstedt
Request for Comments: 9700 SPRIND Request for Comments: 9700 SPRIND
BCP: 240 J. Bradley BCP: 240 J. Bradley
Updates: 6749, 6750, 6819 Yubico Updates: 6749, 6750, 6819 Yubico
Category: Best Current Practice A. Labunets Category: Best Current Practice A. Labunets
ISSN: 2070-1721 Independent Researcher ISSN: 2070-1721 Independent Researcher
D. Fett D. Fett
Authlete Authlete
November 2024 November 2024
OAuth 2.0 Security Best Current Practice Best Current Practice for OAuth 2.0 Security
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 threat model and security advice given in It updates and extends the threat model and security advice given in
RFCs 6749, 6750, and 6819 to incorporate practical experiences RFCs 6749, 6750, and 6819 to incorporate practical experiences
gathered since OAuth 2.0 was published and covers new threats gathered since OAuth 2.0 was published and covers new threats
relevant due to the broader application of OAuth 2.0. Further, it relevant due to the broader application of OAuth 2.0. Further, it
deprecates some modes of operation that are deemed less secure or deprecates some modes of operation that are deemed less secure or
even insecure. even insecure.
skipping to change at line 71 skipping to change at line 71
2.1.2. Implicit Grant 2.1.2. Implicit Grant
2.2. Token Replay Prevention 2.2. Token Replay Prevention
2.2.1. Access Tokens 2.2.1. Access Tokens
2.2.2. Refresh Tokens 2.2.2. Refresh Tokens
2.3. Access Token Privilege Restriction 2.3. Access Token Privilege Restriction
2.4. Resource Owner Password Credentials Grant 2.4. Resource Owner Password Credentials Grant
2.5. Client Authentication 2.5. Client Authentication
2.6. Other Recommendations 2.6. Other Recommendations
3. The Updated OAuth 2.0 Attacker Model 3. The Updated OAuth 2.0 Attacker Model
4. Attacks and Mitigations 4. Attacks and Mitigations
4.1. Insufficient Redirect URI Validation 4.1. Insufficient Redirection URI Validation
4.1.1. Redirect URI Validation Attacks on Authorization Code 4.1.1. Redirect URI Validation Attacks on Authorization Code
Grant Grant
4.1.2. Redirect URI Validation Attacks on Implicit Grant 4.1.2. Redirect URI Validation Attacks on Implicit Grant
4.1.3. Countermeasures 4.1.3. Countermeasures
4.2. Credential Leakage via Referer Headers 4.2. Credential Leakage via Referer Headers
4.2.1. Leakage from the OAuth Client 4.2.1. Leakage from the OAuth Client
4.2.2. Leakage from the Authorization Server 4.2.2. Leakage from the Authorization Server
4.2.3. Consequences 4.2.3. Consequences
4.2.4. Countermeasures 4.2.4. Countermeasures
4.3. Credential Leakage via Browser History 4.3. Credential Leakage via Browser History
skipping to change at line 135 skipping to change at line 135
4.17.1.1. Insufficient Limitation of Receiver Origins 4.17.1.1. Insufficient Limitation of Receiver Origins
4.17.1.2. Insufficient URI Validation 4.17.1.2. Insufficient URI Validation
4.17.1.3. Injection after Insufficient Validation of Sender 4.17.1.3. Injection after Insufficient Validation of Sender
Origin Origin
4.17.2. Recommendations 4.17.2. Recommendations
5. IANA Considerations 5. IANA Considerations
6. Security Considerations 6. Security Considerations
7. References 7. References
7.1. Normative References 7.1. Normative References
7.2. Informative References 7.2. Informative References
Appendix A. Acknowledgements Acknowledgements
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
Since its publication in [RFC6749] and [RFC6750], OAuth 2.0 (referred Since its publication in [RFC6749] and [RFC6750], OAuth 2.0 (referred
to as simply "OAuth" in this document) has gained massive traction in to as simply "OAuth" in this document) has gained massive traction in
the market and became the standard for API protection and the basis the market and became the standard for API protection and the basis
for federated login using OpenID Connect [OpenID.Core]. While OAuth for federated login using OpenID Connect [OpenID.Core]. While OAuth
is used in a variety of scenarios and different kinds of deployments, is used in a variety of scenarios and different kinds of deployments,
the following challenges can be observed: the following challenges can be observed:
skipping to change at line 209 skipping to change at line 209
Nonetheless, it is RECOMMENDED that implementers upgrade their Nonetheless, it is RECOMMENDED that implementers upgrade their
implementations and ecosystems as soon as feasible. implementations and ecosystems as soon as feasible.
OAuth 2.1, under development as [OAUTH-V2.1], will incorporate OAuth 2.1, under development as [OAUTH-V2.1], will incorporate
security recommendations from this document. security recommendations from this document.
1.1. Structure 1.1. Structure
The remainder of this document is organized as follows: Section 2 The remainder of this document is organized as follows: Section 2
summarizes the most important best practices for every OAuth summarizes the most important best practices for every OAuth
implementor. Section 3 presents the updated OAuth attacker model. implementer. Section 3 presents the updated OAuth attacker model.
Section 4 is a detailed analysis of the threats and implementation Section 4 is a detailed analysis of the threats and implementation
issues that can be found in the wild (at the time of writing) along issues that can be found in the wild (at the time of writing) along
with a discussion of potential countermeasures. with a discussion of potential countermeasures.
1.2. Conventions and Terminology 1.2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
skipping to change at line 241 skipping to change at line 241
2. Best Practices 2. Best Practices
This section describes the core set of security mechanisms and This section describes the core set of security mechanisms and
measures that are considered to be best practices at the time of measures that are considered to be best practices at the time of
writing. Details about these security mechanisms and measures writing. Details about these security mechanisms and measures
(including detailed attack descriptions) and requirements for less (including detailed attack descriptions) and requirements for less
commonly used options are provided in Section 4. commonly used options are provided in Section 4.
2.1. Protecting Redirect-Based Flows 2.1. Protecting Redirect-Based Flows
When comparing client redirect URIs against pre-registered URIs, When comparing client redirection URIs against pre-registered URIs,
authorization servers MUST utilize exact string matching except for authorization servers MUST utilize exact string matching except for
port numbers in localhost redirection URIs of native apps (see port numbers in localhost redirection URIs of native apps (see
Section 4.1.3). This measure contributes to the prevention of Section 4.1.3). This measure contributes to the prevention of
leakage of authorization codes and access tokens (see Section 4.1). leakage of authorization codes and access tokens (see Section 4.1).
It can also help to detect mix-up attacks (see Section 4.4). It can also help to detect mix-up attacks (see Section 4.4).
Clients and authorization servers MUST NOT expose URLs that forward Clients and authorization servers MUST NOT expose URLs that forward
the user's browser to arbitrary URIs obtained from a query parameter the user's browser to arbitrary URIs obtained from a query parameter
(open redirectors) as described in Section 4.11. Open redirectors (open redirectors) as described in Section 4.11. Open redirectors
can enable exfiltration of authorization codes and access tokens. can enable exfiltration of authorization codes and access tokens.
skipping to change at line 272 skipping to change at line 272
agent MUST be used for CSRF protection (see Section 4.7.1). agent MUST be used for CSRF protection (see Section 4.7.1).
When an OAuth client can interact with more than one authorization When an OAuth client can interact with more than one authorization
server, a defense against mix-up attacks (see Section 4.4) is server, a defense against mix-up attacks (see Section 4.4) is
REQUIRED. To this end, clients SHOULD REQUIRED. To this end, clients SHOULD
* use the iss parameter as a countermeasure according to [RFC9207], * use the iss parameter as a countermeasure according to [RFC9207],
or or
* use an alternative countermeasure based on an iss value in the * use an alternative countermeasure based on an iss value in the
authorization response (such as the iss claim in the ID Token in authorization response (such as the iss claim in the ID Token in
[OpenID.Core] or in [OpenID.JARM] responses), processing it as [OpenID.Core] or in [OpenID.JARM] responses), processing that
described in [RFC9207]. value as described in [RFC9207].
In the absence of these options, clients MAY instead use distinct In the absence of these options, clients MAY instead use distinct
redirect URIs to identify authorization endpoints and token redirection URIs to identify authorization endpoints and token
endpoints, as described in Section 4.4.2. endpoints, as described in Section 4.4.2.
An authorization server that redirects a request potentially An authorization server that redirects a request potentially
containing user credentials MUST avoid forwarding these user containing user credentials MUST avoid forwarding these user
credentials accidentally (see Section 4.12 for details). credentials accidentally (see Section 4.12 for details).
2.1.1. Authorization Code Grant 2.1.1. Authorization Code Grant
Clients MUST prevent authorization code injection attacks (see Clients MUST prevent authorization code injection attacks (see
Section 4.5) and misuse of authorization codes using one of the Section 4.5) and misuse of authorization codes using one of the
skipping to change at line 314 skipping to change at line 314
preventing the use of constant values for the PKCE challenge or preventing the use of constant values for the PKCE challenge or
OpenID Connect nonce. OpenID Connect nonce.
Note: Although PKCE was designed as a mechanism to protect native Note: Although PKCE was designed as a mechanism to protect native
apps, this advice applies to all kinds of OAuth clients, including apps, this advice applies to all kinds of OAuth clients, including
web applications. web applications.
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].
If a client sends a valid PKCE code_challenge parameter in the If a client sends a valid PKCE code_challenge parameter in the
authorization request, the authorization server MUST enforce the authorization request, the authorization server MUST enforce the
correct usage of code_verifier at the token endpoint. correct usage of code_verifier at the token endpoint.
Authorization servers MUST mitigate PKCE downgrade attacks by Authorization servers MUST mitigate PKCE downgrade attacks by
ensuring that a token request containing a code_verifier parameter is ensuring that a token request containing a code_verifier parameter is
skipping to change at line 338 skipping to change at line 338
Authorization servers MUST provide a way to detect their support for Authorization servers MUST provide a way to detect their support for
PKCE. It is RECOMMENDED for authorization servers to publish the PKCE. It is RECOMMENDED for authorization servers to publish the
element code_challenge_methods_supported in their Authorization element code_challenge_methods_supported in their Authorization
Server Metadata [RFC8414] containing the supported PKCE challenge Server Metadata [RFC8414] containing the supported PKCE challenge
methods (which can be used by the client to detect PKCE support). methods (which can be used by the client to detect PKCE support).
Authorization servers MAY instead provide a deployment-specific way Authorization servers MAY instead provide a deployment-specific way
to ensure or determine PKCE support by the authorization server. to ensure or determine PKCE support by the authorization server.
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 Sections 4.1, 4.2, 4.3, and 4.6. access token replay as described in Sections 4.1, 4.2, 4.3, and 4.6.
Moreover, no standardized method for sender-constraining exists to Moreover, no standardized method for sender-constraining exists to
bind access tokens to a specific client (as recommended in bind access tokens to a specific client (as recommended in
Section 2.2) when the access tokens are issued in the authorization Section 2.2) when the access tokens are issued in the authorization
response. This means that an attacker can use the leaked or stolen response. This means that an attacker can use the leaked or stolen
access token at a resource endpoint. access token at a resource endpoint.
In order to avoid these issues, clients SHOULD NOT use the implicit In order to avoid these issues, clients SHOULD NOT use the implicit
grant (response type "token") or other response types issuing access grant (response type token) or other response types issuing access
tokens in the authorization response, unless access token injection tokens in the authorization response, unless access token injection
in the authorization response is prevented and the aforementioned in the authorization response is prevented and the aforementioned
token leakage vectors are mitigated. token leakage vectors are mitigated.
Clients SHOULD instead use the response type code (i.e., Clients SHOULD instead use the response type code (i.e.,
authorization code grant type) as specified in Section 2.1.1 or any authorization code grant type) as specified in Section 2.1.1 or any
other response type that causes the authorization server to issue other response type that causes the authorization server to issue
access tokens in the token response, such as the code id_token access tokens in the token response, such as the code id_token
response type. This allows the authorization server to detect replay response type. This allows the authorization server to detect replay
attempts by attackers and generally reduces the attack surface since attempts by attackers and generally reduces the attack surface since
skipping to change at line 375 skipping to change at line 375
2.2. Token Replay Prevention 2.2. Token Replay Prevention
2.2.1. Access Tokens 2.2.1. Access Tokens
A sender-constrained access token scopes the applicability of an A sender-constrained access token scopes the applicability of an
access token to a certain sender. This sender is obliged to access token to a certain sender. This sender is obliged to
demonstrate knowledge of a certain secret as a prerequisite for the demonstrate knowledge of a certain secret as a prerequisite for the
acceptance of that token at the recipient (e.g., a resource server). acceptance of that token at the recipient (e.g., a resource server).
Authorization and resource servers SHOULD use mechanisms for sender- Authorization and resource servers SHOULD use mechanisms for sender-
constraining access tokens, such as Mutual TLS for OAuth 2.0 constraining access tokens, such as mutual TLS for OAuth 2.0
[RFC8705] or OAuth 2.0 Demonstrating Proof of Possession (DPoP) [RFC8705] or OAuth 2.0 Demonstrating Proof of Possession (DPoP)
[RFC9449] (see Section 4.10.1), to prevent misuse of stolen and [RFC9449] (see Section 4.10.1), to prevent misuse of stolen and
leaked access tokens. leaked access tokens.
2.2.2. Refresh Tokens 2.2.2. Refresh Tokens
Refresh tokens for public clients MUST be sender-constrained or use Refresh tokens for public clients MUST be sender-constrained or use
refresh token rotation as described in Section 4.14. [RFC6749] refresh token rotation as described in Section 4.14. [RFC6749]
already mandates that refresh tokens for confidential clients can already mandates that refresh tokens for confidential clients can
only be used by the client for which they were issued. only be used by the client for which they were issued.
skipping to change at line 425 skipping to change at line 425
particular resource. If not, the resource server must refuse to particular resource. If not, the resource server must refuse to
serve the respective request. Clients and authorization servers MAY serve the respective request. Clients and authorization servers MAY
utilize the parameter scope as specified in [RFC6749] and utilize the parameter scope as specified in [RFC6749] and
authorization_details as specified in [RFC9396] to determine those authorization_details as specified in [RFC9396] to determine those
resources and/or actions. resources and/or actions.
2.4. Resource Owner Password Credentials Grant 2.4. Resource Owner Password Credentials Grant
The resource owner password credentials grant [RFC6749] MUST NOT be The resource owner password credentials grant [RFC6749] MUST NOT be
used. This grant type insecurely exposes the credentials of the used. This grant type insecurely exposes the credentials of the
resource owner to the client. Even if the client is benign, this resource owner to the client. Even if the client is benign, usage of
results in an increased attack surface (credentials can leak in more this grant results in an increased attack surface (i.e., credentials
places than just the authorization server) and users are trained to can leak in more places than just the authorization server) and in
enter their credentials in places other than the authorization training users to enter their credentials in places other than the
server. authorization server.
Furthermore, the resource owner password credentials grant is not Furthermore, the resource owner password credentials grant is not
designed to work with two-factor authentication and authentication designed to work with two-factor authentication and authentication
processes that require multiple user interaction steps. processes that require multiple user interaction steps.
Authentication with cryptographic credentials (cf. WebCrypto Authentication with cryptographic credentials (cf. WebCrypto
[W3C.WebCrypto], WebAuthn [W3C.WebAuthn]) may be impossible to [W3C.WebCrypto], WebAuthn [W3C.WebAuthn]) may be impossible to
implement with this grant type, as it is usually bound to a specific implement with this grant type, as it is usually bound to a specific
web origin. web origin.
2.5. Client Authentication 2.5. Client Authentication
Authorization servers SHOULD enforce client authentication if it is Authorization servers SHOULD enforce client authentication if it is
feasible, in the particular deployment, to establish a process for feasible, in the particular deployment, to establish a process for
issuance/registration of credentials for clients and ensuring the issuance/registration of credentials for clients and ensuring the
confidentiality of those credentials. confidentiality of those credentials.
It is RECOMMENDED to use asymmetric cryptography for client It is RECOMMENDED to use asymmetric cryptography for client
authentication, such as mutual TLS (mTLS) [RFC8705] or signed JWTs authentication, such as mutual TLS for OAuth 2.0 [RFC8705] or signed
("Private Key JWT") in accordance with [RFC7521] and [RFC7523] (in JWTs ("Private Key JWT") in accordance with [RFC7521] and [RFC7523].
[OpenID.Core] defined as the client authentication method The latter is defined in [OpenID.Core] as the client authentication
private_key_jwt). When asymmetric cryptography for client method private_key_jwt). When asymmetric cryptography for client
authentication is used, authorization servers do not need to store authentication is used, authorization servers do not need to store
sensitive symmetric keys, making these methods more robust against sensitive symmetric keys, making these methods more robust against
leakage of keys. leakage of keys.
2.6. Other Recommendations 2.6. Other Recommendations
The use of OAuth Authorization Server Metadata [RFC8414] can help to The use of OAuth Authorization Server Metadata [RFC8414] can help to
improve the security of OAuth deployments: improve the security of OAuth deployments:
* It ensures that security features and other new OAuth features can * It ensures that security features and other new OAuth features can
skipping to change at line 475 skipping to change at line 475
* It can help to facilitate rotation of cryptographic keys and to * It can help to facilitate rotation of cryptographic keys and to
ensure cryptographic agility. ensure cryptographic agility.
It is therefore RECOMMENDED that authorization servers publish OAuth It is therefore RECOMMENDED that authorization servers publish OAuth
Authorization Server Metadata according to [RFC8414] and that clients Authorization Server Metadata according to [RFC8414] and that clients
make use of this Authorization Server Metadata (when available) to make use of this Authorization Server Metadata (when available) to
configure themselves. configure themselves.
Under the conditions described in Section 4.15.1, authorization Under the conditions described in Section 4.15.1, authorization
servers SHOULD NOT allow clients to influence their client_id or any servers SHOULD NOT allow clients to influence their client_id or any
claim that could cause confusion with a genuine resource owner. other claim that could cause confusion with a genuine resource owner.
It is RECOMMENDED to use end-to-end TLS according to [BCP195] between It is RECOMMENDED to use end-to-end TLS according to [BCP195] between
the client and the resource server. If TLS traffic needs to be the client and the resource server. If TLS traffic needs to be
terminated at an intermediary, refer to Section 4.13 for further terminated at an intermediary, refer to Section 4.13 for further
security advice. security advice.
Authorization responses MUST NOT be transmitted over unencrypted Authorization responses MUST NOT be transmitted over unencrypted
network connections. To this end, authorization servers MUST NOT network connections. To this end, authorization servers MUST NOT
allow redirect URIs that use the http scheme except for native allow redirection URIs that use the http scheme except for native
clients that use loopback interface redirection as described in clients that use loopback interface redirection as described in
Section 7.3 of [RFC8252]. Section 7.3 of [RFC8252].
If the authorization response is sent with in-browser communication If the authorization response is sent with in-browser communication
techniques like postMessage [WHATWG.postmessage_api] instead of HTTP techniques like postMessage [WHATWG.postmessage_api] instead of HTTP
redirects, both the initiator and receiver of the in-browser message redirects, both the initiator and receiver of the in-browser message
MUST be strictly verified as described in Section 4.17. MUST be strictly verified as described in Section 4.17.
To support browser-based clients, endpoints directly accessed by such To support browser-based clients, endpoints directly accessed by such
clients including the Token Endpoint, Authorization Server Metadata clients including the Token Endpoint, Authorization Server Metadata
skipping to change at line 540 skipping to change at line 540
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
navigate their browser to arbitrary attacker-chosen URIs at any navigate their browser to arbitrary attacker-chosen URIs at any
time. In practice, this can be achieved in many ways, for time. In practice, this can be achieved in many ways, for
example, by injecting malicious advertisements into example, by injecting malicious advertisements into
advertisement networks or by sending legitimate-looking emails. advertisement networks or by sending legitimate-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 example, if a web attacker learns an authorization code of a
user through a misconfigured redirect URI, the web attacker can user through a misconfigured redirection URI, the web attacker
then try to redeem that code for an access token. can then 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 of an authorization
attacker-controlled authorization server). server not under control of an attacker).
(A2) Network attackers that additionally have full control over the (A2) Network attackers that additionally have full control over the
network over which protocol participants communicate. They can network over which protocol participants communicate. They can
eavesdrop on, manipulate, and spoof messages, except when these eavesdrop on, manipulate, and spoof messages, except when these
are properly protected by cryptographic methods (e.g., TLS). 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 (Wi-Fi) network service provider itself, an attacker in a public (Wi-Fi) network
skipping to change at line 578 skipping to change at line 578
metadata as described in Section 2.6. Such an attacker is therefore metadata as described in Section 2.6. Such an attacker is therefore
not listed here. not listed here.
However, previous attacks on OAuth have shown that the following However, previous attacks on OAuth have shown that the following
types of attackers are relevant in particular: types of attackers are relevant in particular:
(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 authorization response (i.e., the authorization response can
leak to an attacker). leak to an attacker).
Examples of such attacks include open redirector attacks; Examples of such attacks include open redirector attacks and
insufficient checking of redirect URIs (see Section 4.1); mix-up attacks (see Section 4.4), where the client is tricked
problems existing on mobile operating systems (where different into sending credentials to an attacker-controlled
apps can register themselves on the same URI); mix-up attacks authorization server.
(see Section 4.4), where the client is tricked into sending
credentials to an attacker-controlled authorization server; and Also, this includes attacks that take advantage of:
the fact that URLs are often stored/logged by browsers
(history), proxy servers, and operating systems. * insufficient checking of redirect URIs (see Section 4.1);
* problems existing on mobile operating systems, where
different apps can register themselves on the same URI; and
* URLs stored/logged by browsers (history), proxy servers, and
operating systems.
(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 authorization request (i.e., the authorization request can
leak, in the same manner as above, to an attacker). leak, in the same manner as above, to an attacker).
(A5) Attackers that can acquire an access token issued by an (A5) Attackers that can acquire an access token issued by an
authorization server. For example, a resource server may be authorization server. For example, a resource server may be
compromised by an attacker, an access token may be sent to an compromised by an attacker, an access token may be sent to an
attacker-controlled resource server due to a misconfiguration, attacker-controlled resource server due to a misconfiguration,
or social engineering may be used to get a resource owner to or social engineering may be used to get a resource owner to
use an attacker-controlled resource server. Also see use an attacker-controlled resource server. Also see
Section 4.9.2. Section 4.9.2.
(A3), (A4), and (A5) typically occur together with either (A1) or (A3), (A4), and (A5) typically occur together with either (A1) or
(A2). Attackers can collaborate to reach a common goal. (A2). Attackers can collaborate to reach a common goal.
Note that an attacker (A1) or (A2) can be a resource owner or act as Note that an Attacker (A1) or (A2) can be a resource owner or act as
one. For example, such an attacker can use their own browser to one. For example, such an attacker can use their own browser to
replay tokens or authorization codes obtained by any of the attacks replay tokens or authorization codes obtained by any of the attacks
described above at the client or resource server. described above at the client or resource server.
This document focuses on threats resulting from attackers (A1) to This document focuses on threats resulting from Attackers (A1) to
(A5). (A5).
4. Attacks and Mitigations 4. Attacks and Mitigations
This section gives a detailed description of attacks on OAuth This section gives a detailed description of attacks on OAuth
implementations, along with potential countermeasures. Attacks and implementations, along with potential countermeasures. Attacks and
mitigations already covered in [RFC6819] are not listed here, except mitigations already covered in [RFC6819] are not listed here, except
where new recommendations are made. where new recommendations are made.
This section further defines additional requirements (beyond those This section further defines additional requirements (beyond those
defined in Section 2) for certain cases and protocol options. defined in Section 2) for certain cases and protocol options.
4.1. Insufficient Redirect URI Validation 4.1. Insufficient Redirection URI Validation
Some authorization servers allow clients to register redirect URI Some authorization servers allow clients to register redirection URI
patterns instead of complete redirect URIs. The authorization patterns instead of complete redirection URIs. The authorization
servers then match the redirect URI parameter value at the servers then match the redirection URI parameter value at the
authorization endpoint against the registered patterns at runtime. authorization endpoint against the registered patterns at runtime.
This approach allows clients to encode transaction state into This approach allows clients to encode transaction state into
additional redirect URI parameters or to register a single pattern additional redirect URI parameters or to register a single pattern
for multiple redirect URIs. for multiple redirection URIs.
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 redirection 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 (see, e.g., [research.rub2]). Insufficient validation of the wild (see, e.g., [research.rub2]). Insufficient validation of the
redirect URI effectively breaks client identification or redirection URI effectively breaks client identification or
authentication (depending on grant and client type) and allows the authentication (depending on grant and client type) and allows the
attacker to obtain an authorization code or access token, either attacker to obtain an authorization code or access token, either
* by directly sending the user agent to a URI under the attacker's * by directly sending the user agent to a URI under the attacker's
control, or control, or
* 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:
Assume the redirect URL pattern https://*.somesite.example/* is Assume the redirection URL pattern https://*.somesite.example/* is
registered for the client with the client ID s6BhdRkqt3. The registered for the client with the client ID s6BhdRkqt3. The
intention is to allow any subdomain of somesite.example to be a valid intention is to allow any subdomain of somesite.example to be a valid
redirect URI for the client, for example, redirection URI for the client, for example,
https://app1.somesite.example/redirect. However, a naive https://app1.somesite.example/redirect. However, a naive
implementation on the authorization server might interpret the implementation on the authorization server might interpret the
wildcard * as "any character" and not "any character valid for a wildcard * as "any character" and not "any character valid for a
domain name". The authorization server, therefore, might permit domain name". The authorization server, therefore, might permit
https://attacker.example/.somesite.example as a redirect URI, https://attacker.example/.somesite.example as a redirection URI,
although attacker.example is a different domain potentially although attacker.example is a different domain potentially
controlled by a malicious party. controlled by a malicious party.
The attack can then be conducted as follows: The attack can then be conducted as follows:
To begin, the attacker needs to trick the user into opening a To begin, the attacker needs to trick the user into opening a
tampered URL in their browser that launches a page under the tampered URL in their browser that launches a page under the
attacker's control, say, https://www.evil.example (see attacker A1 in attacker's control, say, https://www.evil.example (see attacker A1 in
Section 3). Section 3).
This URL initiates the following authorization request with the This URL initiates the following authorization request with the
client ID of a legitimate client to the authorization endpoint (line client ID of a legitimate client to the authorization endpoint (line
breaks for display only): breaks for display only):
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=9ad67f13 GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=9ad67f13
&redirect_uri=https%3A%2F%2Fattacker.example%2F.somesite.example &redirect_uri=https%3A%2F%2Fattacker.example%2F.somesite.example
HTTP/1.1 HTTP/1.1
Host: server.somesite.example Host: server.somesite.example
The authorization server validates the redirect URI and compares it The authorization server validates the redirection URI and compares
to the registered redirect URL patterns for the client s6BhdRkqt3. it to the registered redirection URL patterns for the client
The authorization request is processed and presented to the user. s6BhdRkqt3. The authorization request is processed and presented to
the user.
If the user does not see the redirect URI or does not recognize the If the user does not see the redirection URI or does not recognize
attack, the code is issued and immediately sent to the attacker's the attack, the code is issued and immediately sent to the attacker's
domain. If an automatic approval of the authorization is enabled domain. If an automatic approval of the authorization is enabled
(which is not recommended for public clients according to [RFC6749]), (which is not recommended for public clients according to [RFC6749]),
the attack can be performed even without user interaction. the attack can be performed even without user interaction.
If the attacker impersonates a public client, the attacker can If the attacker impersonates a public client, the attacker can
exchange the code for tokens at the respective token endpoint. exchange the code for tokens at the respective token endpoint.
This attack will not work as easily for confidential clients, since This attack will not work as easily for confidential clients, since
the code exchange requires authentication with the legitimate the code exchange requires authentication with the legitimate
client's secret. However, the attacker can use the legitimate client's secret. However, the attacker can use the legitimate
confidential client to redeem the code by performing an authorization confidential client to redeem the code by performing an authorization
code injection attack; see Section 4.5. code injection attack; see Section 4.5.
It is important to note that redirect URI validation vulnerabilities It is important to note that redirection URI validation
can also exist if the authorization server handles wildcards vulnerabilities can also exist if the authorization server handles
properly. For example, assume that the client registers the redirect wildcards properly. For example, assume that the client registers
URL pattern https://*.somesite.example/* and the authorization server the redirection URL pattern https://*.somesite.example/* and the
interprets this as "allow redirect URIs pointing to any host residing authorization server interprets this as "allow redirection URIs
in the domain somesite.example". If an attacker manages to establish pointing to any host residing in the domain somesite.example". If an
a host or subdomain in somesite.example, the attacker can impersonate attacker manages to establish a host or subdomain in
the legitimate client. For example, this could be caused by a somesite.example, the attacker can impersonate the legitimate client.
subdomain takeover attack [research.udel], where an outdated CNAME For example, this could be caused by a subdomain takeover attack
record (say, external-service.somesite.example) points to an external [research.udel], where an outdated CNAME record (say, external-
DNS name that no longer exists (say, customer-abc.service.example) service.somesite.example) points to an external DNS name that no
and can be taken over by an attacker (e.g., by registering as longer exists (say, customer-abc.service.example) and can be taken
customer-abc with the external service). over by an attacker (e.g., by registering as customer-abc with the
external service).
4.1.2. Redirect URI Validation Attacks on Implicit Grant 4.1.2. Redirect URI Validation Attacks on Implicit Grant
The attack described above works for the implicit grant as well. If The attack described above works for the implicit grant as well. If
the attacker is able to send the authorization response to an the attacker is able to send the authorization response to an
attacker-controlled URI, the attacker will directly get access to the attacker-controlled URI, the attacker will directly get access to the
fragment carrying the access token. fragment carrying the access token.
Additionally, implicit grants (and also other grants when using Additionally, implicit grants (and also other grants when using
response_mode=fragment as defined in [OAuth.Responses]) can be response_mode=fragment as defined in [OAuth.Responses]) can be
subject to a further kind of attack. The attack utilizes the fact subject to a further kind of attack. The attack utilizes the fact
that user agents reattach fragments to the destination URL of a that user agents reattach fragments to the destination URL of a
redirect if the location header does not contain a fragment (see redirect if the location header does not contain a fragment (see
Section 17.11 of [RFC9110]). The attack described here combines this Section 17.11 of [RFC9110]). The attack described here combines this
behavior with the client as an open redirector (see Section 4.11.1) behavior with the client as an open redirector (see Section 4.11.1)
in order to obtain access tokens. This allows circumvention even of in order to obtain access tokens. This allows circumvention even of
very narrow redirect URI patterns, but not of strict URL matching. very narrow redirection URI patterns, but not of strict URL matching.
Assume the registered URL pattern for client s6BhdRkqt3 is Assume the registered URL pattern for client s6BhdRkqt3 is
https://client.somesite.example/cb?*, i.e., any parameter is allowed https://client.somesite.example/cb?*, i.e., any parameter is allowed
for redirects to https://client.somesite.example/cb. Unfortunately, for redirects to https://client.somesite.example/cb. Unfortunately,
the client exposes an open redirector. This endpoint supports a the client exposes an open redirector. This endpoint supports a
parameter redirect_to which takes a target URL and will send the parameter redirect_to which takes a target URL and will send the
browser to this URL using an HTTP Location header redirect 303. browser to this URL using an HTTP Location header redirect 303.
The attack can now be conducted as follows: The attack can now be conducted as follows:
To begin, as above, the attacker needs to trick the user into opening To begin, as above, the attacker needs to trick the user into opening
a tampered URL in their browser that launches a page under the a tampered URL in their browser that launches a page under the
attacker's control, say, https://www.evil.example. attacker's control, say, https://www.evil.example.
Afterwards, the website initiates an authorization request that is Afterwards, the website initiates an authorization request that is
very similar to the one in the attack on the code flow. Different to very similar to the one in the attack on the code flow. Different to
above, it utilizes the open redirector by encoding above, it utilizes the open redirector by encoding
redirect_to=https://attacker.example into the parameters of the redirect_to=https://attacker.example into the parameters of the
redirect URI, and it uses the response type "token" (line breaks for redirection URI, and it uses the response type token (line breaks for
display only): display only):
GET /authorize?response_type=token&state=9ad67f13 GET /authorize?response_type=token&state=9ad67f13
&client_id=s6BhdRkqt3 &client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.somesite.example &redirect_uri=https%3A%2F%2Fclient.somesite.example
%2Fcb%26redirect_to%253Dhttps%253A%252F %2Fcb%26redirect_to%253Dhttps%253A%252F
%252Fattacker.example%252F HTTP/1.1 %252Fattacker.example%252F HTTP/1.1
Host: server.somesite.example Host: server.somesite.example
Then, since the redirect URI matches the registered pattern, the Then, since the redirection URI matches the registered pattern, the
authorization server permits the request and sends the resulting authorization server permits the request and sends the resulting
access token in a 303 redirect (some response parameters omitted for access token in a 303 redirect (some response parameters omitted for
readability): readability):
HTTP/1.1 303 See Other HTTP/1.1 303 See Other
Location: https://client.somesite.example/cb? Location: https://client.somesite.example/cb?
redirect_to%3Dhttps%3A%2F%2Fattacker.example%2Fcb redirect_to%3Dhttps%3A%2F%2Fattacker.example%2Fcb
#access_token=2YotnFZFEjr1zCsicMWpAA&... #access_token=2YotnFZFEjr1zCsicMWpAA&...
At client.somesite.example, the request arrives at the open At client.somesite.example, the request arrives at the open
skipping to change at line 790 skipping to change at line 796
https://attacker.example/#access_token=2YotnFZFEjr1z... https://attacker.example/#access_token=2YotnFZFEjr1z...
The attacker's page at attacker.example can then access the fragment The attacker's page at attacker.example can then access the fragment
and obtain the access token. and obtain the access token.
4.1.3. Countermeasures 4.1.3. Countermeasures
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 simplifying the required logic and configuration by using advises simplifying the required logic and configuration by using
exact redirect URI matching. This means the authorization server exact redirection URI matching. This means the authorization server
MUST ensure that the two URIs are equal; see Section 6.2.1 of MUST ensure that the two URIs are equal; see Section 6.2.1 of
[RFC3986], Simple String Comparison, for details. The only exception [RFC3986], Simple String Comparison, for details. The only exception
is native apps using a localhost URI: In this case, the authorization is native apps using a localhost URI: In this case, the authorization
server MUST allow variable port numbers as described in Section 7.3 server MUST allow variable port numbers as described in Section 7.3
of [RFC8252]. of [RFC8252].
Additional recommendations: Additional recommendations:
* Web servers on which redirect URIs are hosted MUST NOT expose open * Web servers on which redirection URIs are hosted MUST NOT expose
redirectors (see Section 4.11). open redirectors (see Section 4.11).
* 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 Location arbitrary fragment identifier, for example #_, to URLs in Location
headers. headers.
* Clients SHOULD use the authorization code response type instead of * Clients SHOULD use the authorization code response type instead of
response types that cause access token issuance at the response types that cause access token issuance at the
authorization endpoint. This offers countermeasures against the authorization endpoint. This offers countermeasures against the
reuse of leaked credentials through the exchange process with the reuse of leaked credentials through the exchange process with the
authorization server and against token replay through sender- authorization server and against token replay through sender-
constraining of the access tokens. constraining of the access 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 [RFC9101] the redirection URI can be verified, for example, when using
or [RFC9126] with client authentication, the authorization server MAY [RFC9101] or [RFC9126] with client authentication, the authorization
trust the redirect URI without further checks. server MAY trust the redirection URI without further checks.
4.2. Credential Leakage via Referer Headers 4.2. Credential Leakage via Referer Headers
The contents of the authorization request URI or the authorization The contents of the authorization request URI or the authorization
response URI can unintentionally be disclosed to attackers through response URI can unintentionally be disclosed to attackers through
the Referer HTTP header (see Section 10.1.3 of [RFC9110]), by leaking the Referer HTTP header (see Section 10.1.3 of [RFC9110]), by leaking
from either the authorization server's or the client's website, from either the authorization server's or the client's website,
respectively. Most importantly, authorization codes or state values respectively. Most importantly, authorization codes or state values
can be disclosed in this way. Although specified otherwise in can be disclosed in this way. Although specified otherwise in
Section 10.1.3 of [RFC9110], the same may happen to access tokens Section 10.1.3 of [RFC9110], the same may happen to access tokens
skipping to change at line 952 skipping to change at line 958
Countermeasures: Countermeasures:
* 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.Post] can be used to this end. response mode [OAuth.Post] can be used to this end.
4.4. Mix-Up Attacks 4.4. Mix-Up Attacks
Mix-up attacks are in scenarios where an OAuth client interacts with Mix-up attacks can occur in scenarios where an OAuth client interacts
two or more authorization servers and at least one authorization with 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,
for example, if the attacker uses dynamic registration to register for example, if the attacker uses dynamic registration to register
the client at their own authorization server or if an authorization the client at their own authorization server or if an authorization
server becomes compromised. server becomes compromised.
The goal of the attack is to obtain an authorization code or an The goal of the attack is to obtain an authorization code or an
access token for an uncompromised authorization server. This is access token for an uncompromised authorization server. This is
achieved by tricking the client into sending those credentials to the achieved by tricking the client into sending those credentials to the
compromised authorization server (the attacker) instead of using them compromised authorization server (the attacker) instead of using them
at the respective endpoint of the uncompromised authorization/ at the respective endpoint of the uncompromised authorization/
skipping to change at line 1010 skipping to change at line 1016
authorization endpoint of H-AS. In the authorization request, authorization endpoint of H-AS. In the authorization request,
the attacker replaces the client ID of the client at A-AS with the attacker replaces the client ID of the client at A-AS with
the client's ID at H-AS. Therefore, the browser receives a the client's ID at H-AS. Therefore, the browser receives a
redirection (303 See Other) with a Location header pointing to redirection (303 See Other) with a Location header pointing to
https://honest.as.example/ https://honest.as.example/
authorize?response_type=code&client_id=7ZGZldHQ authorize?response_type=code&client_id=7ZGZldHQ
4. The user authorizes the client to access their resources at H-AS. 4. The user authorizes the client to access their resources at H-AS.
(Note that a vigilant user might at this point detect that they (Note that a vigilant user might at this point detect that they
intended to use A-AS instead of H-AS. The first attack variant intended to use A-AS instead of H-AS. The first attack variant
listed below avoids this.) H-AS issues a code and sends it (via listed does not have this limitation.) H-AS issues a code and
the browser) back to the client. sends it (via the browser) back to the client.
5. Since the client still assumes that the code was issued by A-AS, 5. 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.
6. The attacker therefore obtains code and can either exchange the 6. 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:
skipping to change at line 1039 skipping to change at line 1045
client. In the attack, the user starts the flow with H-AS. The client. In the attack, the user starts the flow with H-AS. The
attacker intercepts this request and changes the user's selection attacker intercepts this request and changes the user's selection
to A-AS. The rest of the attack proceeds as in Step 2 and to A-AS. The rest of the attack proceeds as in Step 2 and
following above. following above.
* 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 in Step 4. The attacker's access token instead of the code in Step 4. The attacker's
authorization server receives the access token when the client authorization server receives the access token when the client
makes either a request to the A-AS userinfo endpoint or a request makes either a request to the A-AS userinfo endpoint or a request
to the attacker's resource server (since the client believes it to the attacker's resource server (since the client believes it
has completed the flow with A-AS). has completed the flow with A-AS).
* Per-AS Redirect URIs: If clients use different redirect URIs for * Per-AS Redirect URIs: If clients use different redirection URIs
different authorization servers, clients do not store the selected for different authorization servers, clients do not store the
authorization server in the user's session, and authorization selected authorization server in the user's session, and
servers do not check the redirect URIs properly, attackers can authorization servers do not check the redirection URIs properly,
mount an attack called "Cross-Social Network Request Forgery". attackers can mount an attack called "Cross-Social Network Request
These attacks have been observed in practice. Refer to Forgery". These attacks have been observed in practice. Refer to
[research.jcs_14] for details. [research.jcs_14] for details.
* OpenID Connect: Some variants can be used to attack OpenID * OpenID Connect: Some variants can be used to attack OpenID
Connect. In these attacks, the attacker misuses features of the Connect. In these attacks, the attacker misuses features of the
OpenID Connect Discovery [OpenID.Discovery] mechanism or replays OpenID Connect Discovery [OpenID.Discovery] mechanism or replays
access tokens or ID Tokens to conduct a mix-up attack. The access tokens or ID Tokens to conduct a mix-up attack. The
attacks are described in detail in Appendix A of attacks are described in detail in Appendix A of
[arXiv.1704.08539] and Section 6 of [arXiv.1508.04324v2] [arXiv.1704.08539] and Section 6 of [arXiv.1508.04324v2]
("Malicious Endpoints Attacks"). ("Malicious Endpoints Attacks").
4.4.2. Countermeasures 4.4.2. Countermeasures
skipping to change at line 1107 skipping to change at line 1113
In both cases, the iss value MUST be evaluated according to In both cases, the iss value MUST be evaluated according to
[RFC9207]. [RFC9207].
While this defense may require deploying new OAuth features to While this defense may require deploying new OAuth features to
transport the issuer information, it is a robust and relatively transport the issuer information, it is a robust and relatively
simple defense against mix-up. simple defense against mix-up.
4.4.2.2. Mix-Up Defense via Distinct Redirect URIs 4.4.2.2. Mix-Up Defense via Distinct Redirect URIs
For this defense, clients MUST use a distinct redirect URI for each For this defense, clients MUST use a distinct redirection URI for
issuer they interact with. each issuer they interact with.
Clients MUST check that the authorization response was received from Clients MUST check that the authorization response was received from
the correct issuer by comparing the distinct redirect URI for the the correct issuer by comparing the distinct redirection URI for the
issuer to the URI where the authorization response was received on. issuer to the URI where the authorization response was received on.
If there is a mismatch, the client MUST abort the flow. If there is a mismatch, the client MUST abort the flow.
While this defense builds upon existing OAuth functionality, it While this defense builds upon existing OAuth functionality, it
cannot be used in scenarios where clients only register once for the cannot be used in scenarios where clients only register once for the
use of many different issuers (as in some open banking schemes) and use of many different issuers (as in some open banking schemes) and
due to the tight integration with the client registration, it is due to the tight integration with the client registration, it is
harder to deploy automatically. harder to deploy automatically.
Furthermore, an attacker might be able to circumvent the protection Furthermore, an attacker might be able to circumvent the protection
skipping to change at line 1141 skipping to change at line 1147
4.5. Authorization Code Injection 4.5. Authorization Code Injection
An attacker who has gained access to an authorization code contained An attacker who has gained access to an authorization code contained
in an authorization response (see Attacker (A3) in Section 3) can try in an authorization response (see Attacker (A3) in Section 3) can try
to redeem the authorization code for an access token or otherwise to redeem the authorization code for an access token or otherwise
make use of the authorization code. make use of the authorization code.
In the case that the authorization code was created for a public In the case that the authorization code was created for a public
client, the attacker can send the authorization code to the token client, the attacker can send the authorization code to the token
endpoint of the authorization server and thereby get an access token. endpoint of the authorization server and thereby get an access token.
This attack was described in Section 4.4.1.1. of [RFC6819]. This attack was described in Section 4.4.1.1 of [RFC6819].
For confidential clients, or in some special situations, the attacker For confidential clients, or in some special situations, the attacker
can execute an authorization code injection attack, as described in can execute an authorization code injection attack, as described in
the following. the following.
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, thereby giving the client with the victim's resources or identity, thereby giving
the attacker at least limited access to the victim's resources. the attacker at least limited access to the victim's resources.
skipping to change at line 1188 skipping to change at line 1194
code with the stolen authorization code. Since this response is code with the stolen authorization code. Since this response is
passing through the attacker's device, the attacker can use any passing through the attacker's device, the attacker can use any
tool that can intercept and manipulate the authorization response tool that can intercept and manipulate the authorization response
to this end. The attacker does not need to control the network. to this end. The attacker does not need to control the network.
4. The legitimate client sends the code to the authorization 4. The legitimate client sends the code to the authorization
server's token endpoint, along with the redirect_uri and the server's token endpoint, along with the redirect_uri and the
client's client ID and client secret (or other means of client client's client ID and client secret (or other means of client
authentication). authentication).
5. The authorization server checks the client secret, whether the 5. The authorization server checks the client secret, whether the
code was issued to the particular client, and whether the actual code was issued to the particular client, and whether the actual
redirect URI matches the redirect_uri parameter (see [RFC6749]). redirection URI matches the redirect_uri parameter (see
[RFC6749]).
6. All checks succeed and the authorization server issues access and 6. All checks succeed and the authorization server issues access and
other tokens to the client. The attacker has now associated other tokens to the client. The attacker has now associated
their session with the legitimate client with the victim's their session with the legitimate client with the victim's
resources and/or identity. resources and/or identity.
4.5.2. Discussion 4.5.2. Discussion
Obviously, the check-in step (Step 5) will fail if the code was Obviously, the check-in step (Step 5) will fail if the code was
issued to another client ID, e.g., a client set up by the attacker. issued to another client ID, e.g., a client set up by the attacker.
The check will also fail if the authorization code was already The check will also fail if the authorization code was already
redeemed by the legitimate user and was one-time use only. redeemed by the legitimate user and was one-time use only.
An attempt to inject a code obtained via a manipulated redirect URI An attempt to inject a code obtained via a manipulated redirection
should also be detected if the authorization server stored the URI should also be detected if the authorization server stored the
complete redirect URI used in the authorization request and compares complete redirection URI used in the authorization request and
it with the redirect_uri parameter. compares it with the redirect_uri parameter.
Section 4.1.3 of [RFC6749] requires the authorization server to Section 4.1.3 of [RFC6749] requires the authorization server to
| ensure that the "redirect_uri" parameter is present if the | ensure that the "redirect_uri" parameter is present if the
| "redirect_uri" parameter was included in the initial authorization | "redirect_uri" parameter was included in the initial authorization
| request as described in Section 4.1.1, and if included ensure that | request as described in Section 4.1.1, and if included ensure that
| their values are identical. | their values are identical.
In the attack scenario described in Section 4.5.1, the legitimate In the attack scenario described in Section 4.5.1, the legitimate
client would use the correct redirect URI it always uses for client would use the correct redirection URI it always uses for
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 redirection URI used by the attacker (otherwise, the redirect would
land at the attacker's page). So, the authorization server would not land at the attacker's page). So, the authorization server would
detect the attack and refuse to exchange the code. detect the attack and refuse to exchange the code.
This check could also detect attempts to inject an authorization code This check could also detect attempts to inject an authorization code
that had been obtained from another instance of the same client on that had been obtained from another instance of the same client on
another device if certain conditions are fulfilled: another device if certain conditions are fulfilled:
* the redirect URI itself contains a nonce or another kind of one- * the redirection URI itself contains a nonce or another kind of
time use, secret data and one-time use, secret data and
* 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 of enforcing exact But, this approach conflicts with the idea of enforcing exact
redirect URI matching at the authorization endpoint. Moreover, it redirect URI matching at the authorization endpoint. Moreover, it
has been observed that providers very often ignore the redirect_uri has been observed that providers very often ignore the redirect_uri
check requirement at this stage, maybe because it doesn't seem to be check 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 against Other providers just pattern match the redirect_uri parameter against
the registered redirect URI pattern. This saves the authorization the registered redirection URI pattern. This saves the authorization
server from storing the link between the actual redirect URI and the server from storing the link between the actual redirect URI and the
respective authorization code for every transaction. However, this respective authorization code for every transaction. However, this
kind of check obviously does not fulfill the intent of the kind of check obviously does not fulfill the intent of the
specification, since the tampered redirect URI is not considered. specification, since the tampered redirection URI is not considered.
So, any attempt to inject an authorization code obtained using the So, any attempt to inject an authorization code obtained using the
client_id of a legitimate client or by utilizing the legitimate client_id of a legitimate client or by utilizing the legitimate
client on another device will not be detected in the respective client on another device will not be detected in the respective
deployments. deployments.
It is also assumed that the requirements defined in Section 4.1.3 of It is also assumed that the requirements defined in Section 4.1.3 of
[RFC6749] increase client implementation complexity as clients need [RFC6749] increase client implementation complexity as clients need
to store or reconstruct the correct redirect URI for the call to the to store or reconstruct the correct redirection URI for the call to
token endpoint. the token endpoint.
Asymmetric methods for client authentication do not stop this attack, Asymmetric methods for client authentication do not stop this attack,
as the legitimate client authenticates at the token endpoint. as the legitimate client authenticates at the token endpoint.
This document therefore recommends instead binding every This document therefore recommends instead binding 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
skipping to change at line 1384 skipping to change at line 1391
expected in the authorization response. expected in the authorization response.
Note that further protection, like sender-constrained access tokens, Note that further protection, like sender-constrained access tokens,
is still required to prevent attackers from using the access token at is still required to prevent attackers from using the access token at
the resource endpoint directly. the resource endpoint directly.
The recommendations in Section 2.1.2 follow from this. The recommendations in Section 2.1.2 follow from this.
4.7. Cross-Site Request Forgery 4.7. Cross-Site Request Forgery
An attacker might attempt to inject a request to the redirect URI of An attacker might attempt to inject a request to the redirection URI
the legitimate client on the victim's device, e.g., to cause the of the legitimate client on the victim's device, e.g., to cause the
client to access resources under the attacker's control. This is a client to access resources under the attacker's control. This is a
variant of an attack known as Cross-Site Request Forgery (CSRF). variant of an attack known as Cross-Site Request Forgery (CSRF).
4.7.1. Countermeasures 4.7.1. Countermeasures
The long-established countermeasure is that clients pass a random The long-established countermeasure is that clients pass a random
value, also known as a CSRF Token, in the state parameter that links value, also known as a CSRF Token, in the state parameter that links
the request to the redirect URI to the user agent session as the request to the redirection URI to the user agent session as
described. This countermeasure is described in detail in described. This countermeasure is described in detail in
Section 5.3.5 of [RFC6819]. The same protection is provided by PKCE Section 5.3.5 of [RFC6819]. The same protection is provided by PKCE
or the OpenID Connect nonce value. or the OpenID Connect nonce value.
When using PKCE instead of state or nonce for CSRF protection, it is When using PKCE instead of state or nonce for CSRF protection, it is
important to note that: important to note that:
* Clients MUST ensure that the authorization server supports PKCE * Clients MUST ensure that the authorization server supports PKCE
before using PKCE for CSRF protection. If an authorization server before using PKCE for CSRF protection. If an authorization server
does not support PKCE, state or nonce MUST be used for CSRF does not support PKCE, state or nonce MUST be used for CSRF
protection. protection.
* If state is used for carrying application state, and the integrity * If state is used for carrying application state, and the 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 by signing/
state values. One example of this is discussed in the expired encrypting state values. One example of this is discussed in the
Internet-Draft [JWT-ENCODED-STATE]. expired Internet-Draft [JWT-ENCODED-STATE].
The authorization server therefore MUST provide a way to detect their The authorization server therefore MUST provide a way to detect their
support for PKCE. Using Authorization Server Metadata according to support for PKCE. Using Authorization Server Metadata according to
[RFC8414] is RECOMMENDED, but authorization servers MAY instead [RFC8414] is RECOMMENDED, but authorization servers MAY instead
provide a deployment-specific way to ensure or determine PKCE provide a deployment-specific way to ensure or determine PKCE
support. support.
PKCE provides robust protection against CSRF attacks even in the PKCE provides robust protection against CSRF attacks even in the
presence of an attacker that can read the authorization response (see presence of an attacker that can read the authorization response (see
Attacker (A3) in Section 3). When state is used or an ID Token is Attacker (A3) in Section 3). When state is used or an ID Token is
skipping to change at line 1534 skipping to change at line 1541
into sending access tokens to it that are valid for other resource into sending access tokens to it that are valid for other resource
servers (see Attackers (A1) and (A5) in Section 3). If the client servers (see Attackers (A1) and (A5) in Section 3). If the client
sends a valid access token to this counterfeit resource server, the sends a valid access token to this counterfeit resource server, the
attacker in turn may use that token to access other services on attacker in turn may use that token to access other services on
behalf of the resource owner. behalf of the resource owner.
This attack assumes the client is not bound to one specific resource This attack assumes the client is not bound to one specific resource
server (and its URL) at development time, but client instances are server (and its URL) at development time, but client instances are
provided with the resource server URL at runtime. This kind of late provided with the resource server URL at runtime. This kind of late
binding is typical in situations where the client uses a service binding is typical in situations where the client uses a service
implementing a standardized API (e.g., for email, calendar, health, implementing a standardized API (e.g., for email, calendaring,
or banking) and where the client is configured by a user or eHealth, or open banking) and where the client is configured by a
administrator for a service that this user or company uses. user or administrator.
4.9.2. Compromised Resource Server 4.9.2. Compromised Resource Server
An attacker may compromise a resource server to gain access to the An attacker may compromise a resource server to gain access to the
resources of the respective deployment. Such a compromise may range resources of the respective deployment. Such a compromise may range
from partial access to the system, e.g., its log files, to full from partial access to the system, e.g., its log files, to full
control over the respective server, in which case all controls can be control over the respective server, in which case all controls can be
circumvented and all resources can be accessed. The attacker would circumvented and all resources can be accessed. The attacker would
also be able to obtain other access tokens held on the compromised also be able to obtain other access tokens held on the compromised
system that would potentially be valid to access other resource system that would potentially be valid to access other resource
servers. 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. Section 4.9 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.
4.9.3. Countermeasures 4.9.3. Countermeasures
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:
* Sender-constrained access tokens, as described in Section 4.10.1, * Sender-constrained access tokens, as described in Section 4.10.1,
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. If an attacker has only partial tokens on other resource servers. If an attacker has only partial
skipping to change at line 1621 skipping to change at line 1628
tied to specific material provided by the transport layer (e.g., tied to specific material provided by the transport layer (e.g.,
TLS). The resource server must also ensure that a replay of the TLS). The resource server must also ensure that a replay of the
proof of possession is not possible. proof of possession is not possible.
Two methods for sender-constrained access tokens using proof of Two methods for sender-constrained access tokens using proof of
possession have been defined by the OAuth working group and are in possession have been defined by the OAuth working group and are in
use in practice: use in practice:
* "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 specified in this) document Access Tokens" [RFC8705]: The approach specified in this) document
allows the use of mutual TLS (mTLS) for both client authentication allows the use of mutual TLS for both client authentication and
and sender-constrained access tokens. For the purpose of sender- sender-constrained access tokens. For the purpose of sender-
constrained access tokens, the client is identified towards the constrained access tokens, the client is identified towards the
resource server by the fingerprint of its public key. During the resource server by the fingerprint of its public key. During the
processing of an access token request, the authorization server processing of an access token request, the authorization server
obtains the client's public key from the TLS stack and associates obtains the client's public key from the TLS stack and associates
its fingerprint with the respective access tokens. The resource its fingerprint with the respective access tokens. The resource
server in the same way obtains the public key from the TLS stack server in the same way obtains the public key from the TLS stack
and compares its fingerprint with the fingerprint associated with and compares its fingerprint with the fingerprint associated with
the access token. the access token.
* "OAuth 2.0 Demonstrating Proof of Possession (DPoP)" [RFC9449]: * "OAuth 2.0 Demonstrating Proof of Possession (DPoP)" [RFC9449]:
DPoP outlines an application-level sender-constraining for access DPoP outlines an application-level mechanism for sender-
and refresh tokens. It uses proof-of-possession based on a constraining access and refresh tokens. It uses proof-of-
public/private key pair and application-level signing. DPoP can possession based on a public/private key pair and application-
be used with public clients and, in the case of confidential level signing. DPoP can be used with public clients and, in the
clients, can be combined with any client authentication method. case of confidential clients, can be combined with any client
authentication method.
Note that the security of sender-constrained tokens is undermined Note that the security of sender-constrained tokens is undermined
when an attacker gets access to the token and the key material. This when an attacker gets access to the token and the key material. This
is, in particular, the case for corrupted client software and cross- is, in particular, the case for corrupted client software and cross-
site scripting attacks (when the client is running in the browser). site scripting attacks (when the client is running in the browser).
If the key material is protected in a hardware or software security If the key material is protected in a hardware or software security
module or only indirectly accessible (like in a TLS stack), sender- module or only indirectly accessible (like in a TLS stack), sender-
constrained tokens at least protect against the use of the token when constrained tokens at least protect against the use of the token when
the client is offline, i.e., when the security module or interface is the client is offline, i.e., when the security module or interface is
not available to the attacker. This applies to access tokens as well not available to the attacker. This applies to access tokens as well
skipping to change at line 1695 skipping to change at line 1703
benefit to hide the resource server URL from the authorization benefit to hide the resource server URL from the authorization
server. server.
Audience restriction may seem easier to use since it does not require Audience restriction may seem easier to use since it does not require
any cryptography on the client side. Still, since every access token any cryptography on the client side. Still, since every access token
is bound to a specific resource server, the client also needs to is bound to a specific resource server, the client also needs to
obtain a single resource server-specific access token when accessing obtain a single resource server-specific access token when accessing
several resource servers. (Resource indicators, as specified in several resource servers. (Resource indicators, as specified in
[RFC8707], can help to achieve this.) [TOKEN-BINDING] had the same [RFC8707], can help to achieve this.) [TOKEN-BINDING] had the same
property since different token-binding IDs must be associated with property since different token-binding IDs must be associated with
the access token. Using Mutual TLS for OAuth 2.0 [RFC8705], on the the access token. Using mutual TLS for OAuth 2.0 [RFC8705], on the
other hand, allows a client to use the access token at multiple other hand, allows a client to use the access token at multiple
resource servers. resource servers.
It should be noted that audience restrictions -- or, generally It should be noted that audience restrictions -- or, generally
speaking, an indication by the client to the authorization server speaking, an indication by the client to the authorization server
where it wants to use the access token -- have additional benefits where it wants to use the access token -- have additional benefits
beyond the scope of token leakage prevention. They allow the beyond the scope of token leakage prevention. They allow the
authorization server to create a different access token whose format authorization server to create a different access token whose format
and content are specifically minted for the respective server. This and content are specifically minted for the respective server. This
has huge functional and privacy advantages in deployments using has huge functional and privacy advantages in deployments using
skipping to change at line 1760 skipping to change at line 1768
This mitigation strategy would rely on the client to enforce the This mitigation strategy would rely on the client to enforce the
security policy and to only send access tokens to legitimate security policy and to only send access tokens to legitimate
destinations. Results of OAuth-related security research (see, for destinations. Results of OAuth-related security research (see, for
example, [research.ubc] and [research.cmu]) indicate a large portion example, [research.ubc] and [research.cmu]) indicate a large portion
of client implementations do not or fail to properly implement of client implementations do not or fail to properly implement
security controls, like state checks. So, relying on clients to security controls, like state checks. So, relying on clients to
prevent access token phishing is likely to fail as well. Moreover, prevent access token phishing is likely to fail as well. Moreover,
given the ratio of clients to authorization and resource servers, it given the ratio of clients to authorization and resource servers, it
is considered the more viable approach to move as much as possible is considered the more viable approach to move as much as possible
security-related logic to those entities. Clearly, the client has to security-related logic to those servers. Clearly, the client has to
contribute to the overall security. However, there are alternative contribute to the overall security. However, there are alternative
countermeasures, as described before, that provide a better balance countermeasures, as described in Sections 4.10.1 and 4.10.2, that
between the involved parties. provide a better balance between the involved parties.
4.11. Open Redirection 4.11. Open Redirection
The following attacks can occur when an authorization server or The following attacks can occur when an authorization server or
client has an open redirector. Such endpoints are sometimes client has an open redirector. Such endpoints are sometimes
implemented, for example, to show a message before a user is then implemented, for example, to show a message before a user is then
redirected to an external website, or to redirect users back to a URL redirected to an external website, or to redirect users back to a URL
they were intending to visit before being interrupted, e.g., by a they were intending to visit before being interrupted, e.g., by a
login prompt. login prompt.
skipping to change at line 1802 skipping to change at line 1810
performing phishing attacks. OAuth authorization servers regularly performing phishing attacks. OAuth authorization servers regularly
redirect users to other websites (the clients), but they must do so redirect users to other websites (the clients), but they must do so
safely. safely.
Section 4.1.2.1 of [RFC6749] already prevents open redirects by Section 4.1.2.1 of [RFC6749] already prevents open redirects by
stating that the authorization server MUST NOT automatically redirect stating that the authorization server MUST NOT automatically redirect
the user agent in case of an invalid combination of client_id and the user agent in case of an invalid combination of client_id and
redirect_uri. redirect_uri.
However, an attacker could also utilize a correctly registered However, an attacker could also utilize a correctly registered
redirect URI to perform phishing attacks. The attacker could, for redirection URI to perform phishing attacks. The attacker could, for
example, register a client via dynamic client registration [RFC7591] example, register a client via dynamic client registration [RFC7591]
and execute one of the following attacks: and execute one of the following attacks:
1. Intentionally send an erroneous authorization request, e.g., by 1. Intentionally send an erroneous authorization request, e.g., by
using an invalid scope value, thus instructing the authorization using an invalid scope value, thus instructing the authorization
server to redirect the user agent to its phishing site. server to redirect the user agent to its phishing site.
2. Intentionally send a valid authorization request with client_id 2. Intentionally send a valid authorization request with client_id
and redirect_uri controlled by the attacker. After the user and redirect_uri controlled by the attacker. After the user
authenticates, the authorization server prompts the user to authenticates, the authorization server prompts the user to
provide consent to the request. If the user notices an issue provide consent to the request. If the user notices an issue
skipping to change at line 1827 skipping to change at line 1835
3. Intentionally send a valid silent authentication request 3. Intentionally send a valid silent authentication request
(prompt=none) with client_id and redirect_uri controlled by the (prompt=none) with client_id and redirect_uri controlled by the
attacker. In this case, the authorization server will attacker. In this case, the authorization server will
automatically redirect the user agent to the phishing site. automatically redirect the user agent to the phishing site.
The authorization server MUST take precautions to prevent these The authorization server MUST take precautions to prevent these
threats. The authorization server MUST always authenticate the user threats. The authorization server MUST always authenticate the user
first and, with the exception of the silent authentication use case, first and, with the exception of the silent authentication use case,
prompt the user for credentials when needed, before redirecting the prompt the user for credentials when needed, before redirecting the
user. Based on its risk assessment, the authorization server needs user. Based on its risk assessment, the authorization server needs
to decide whether or not it can trust the redirect URI. It could to decide whether or not it can trust the redirection URI. It could
take into account URI analytics done internally or through some take into account URI analytics done internally or through some
external service to evaluate the credibility and trustworthiness of external service to evaluate the credibility and trustworthiness of
content behind the URI, and the source of the redirect URI and other content behind the URI, and the source of the redirection URI and
client data. other client data.
The authorization server SHOULD only automatically redirect the user The authorization server SHOULD only automatically redirect the user
agent if it trusts the redirect URI. If the URI is not trusted, the agent if it trusts the redirection URI. If the URI is not trusted,
authorization server MAY inform the user and rely on the user to make the authorization server MAY inform the user and rely on the user to
the correct decision. make the correct decision.
4.12. 307 Redirect 4.12. 307 Redirect
At the authorization endpoint, a typical protocol flow is that the At the authorization endpoint, a typical protocol flow is that the
authorization server prompts the user to enter their credentials in a authorization server prompts the user to enter their credentials in a
form that is then submitted (using the HTTP POST method) back to the form that is then submitted (using the HTTP POST method) back to the
authorization server. The authorization server checks the authorization server. The authorization server checks the
credentials and, if successful, redirects the user agent to the credentials and, if successful, redirects the user agent to the
client's redirection endpoint. client's redirection endpoint.
skipping to change at line 1865 skipping to change at line 1873
user at the authorization server. user at the authorization server.
The behavior might be unexpected for developers but is defined in The behavior might be unexpected for developers but is defined in
Section 15.4.8 of [RFC9110]. This status code (307) does not require Section 15.4.8 of [RFC9110]. This status code (307) does not require
the user agent to rewrite the POST request to a GET request and the user agent to rewrite the POST request to a GET request and
thereby drop the form data in the POST request body. thereby drop the form data in the POST request body.
In the HTTP standard [RFC9110], only the status code 303 In the HTTP standard [RFC9110], only the status code 303
unambiguously enforces rewriting the HTTP POST request to an HTTP GET unambiguously enforces rewriting the HTTP POST request to an HTTP GET
request. For all other status codes, including the popular 302, user request. For all other status codes, including the popular 302, user
agents can opt not to rewrite POST to GET requests and therefore to agents can opt not to rewrite POST to GET requests, thereby causing
reveal the user's credentials to the client. (In practice, however, the user's credentials to be revealed to the client. (In practice,
most user agents will only show this behavior for 307 redirects.) however, most user agents will only show this behavior for 307
redirects.)
Authorization servers that redirect a request that potentially Authorization servers that redirect a request that potentially
contains the user's credentials therefore MUST NOT use the HTTP 307 contains the user's credentials therefore MUST NOT use the HTTP 307
status code for redirection. If an HTTP redirection (and not, for status code for redirection. If an HTTP redirection (and not, for
example, JavaScript) is used for such a request, the authorization example, JavaScript) is used for such a request, the authorization
server SHOULD use HTTP status code 303 (See Other). server SHOULD use HTTP status code 303 (See Other).
4.13. TLS Terminating Reverse Proxies 4.13. TLS Terminating Reverse Proxies
A common deployment architecture for HTTP applications is to hide the A common deployment architecture for HTTP applications is to hide the
skipping to change at line 1927 skipping to change at line 1936
4.14. Refresh Token Protection 4.14. Refresh Token Protection
Refresh tokens are a convenient and user-friendly way to obtain new Refresh tokens are a convenient and user-friendly way to obtain new
access tokens. They also add to the security of OAuth, since they access tokens. They also add to the security of OAuth, since they
allow the authorization server to issue access tokens with a short allow the authorization server to issue access tokens with a short
lifetime and reduced scope, thus reducing the potential impact of lifetime and reduced scope, thus reducing the potential impact of
access token leakage. access token leakage.
4.14.1. Discussion 4.14.1. Discussion
Refresh tokens are an attractive target for attackers since they Refresh tokens are an attractive target for attackers because they
represent the full scope of grant a resource owner delegated to a represent the full scope of access granted to a certain client, and
certain client and they are not further constrained to a specific they are not further constrained to a specific resource. If an
resource. If an attacker is able to exfiltrate and successfully attacker is able to exfiltrate and successfully replay a refresh
replay a refresh token, the attacker will be able to mint access token, the attacker will be able to mint access tokens and use them
tokens and use them to access resource servers on behalf of the to access resource servers on behalf of the resource owner.
resource owner.
[RFC6749] already provides robust baseline protection by requiring [RFC6749] already provides robust baseline protection by requiring
* confidentiality of the refresh tokens in transit and storage, * confidentiality of the refresh tokens in transit and storage,
* 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,
* 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 and authentication of this refresh token to a certain client and authentication of this
client during token refresh, if possible, and client during token refresh, if possible, and
* that refresh tokens cannot be generated, modified, or guessed. * that refresh tokens cannot be generated, modified, or guessed.
skipping to change at line 2046 skipping to change at line 2054
between access tokens obtained with involvement of the resource owner between access tokens obtained with involvement of the resource owner
and those without, the client may accidentally be able to access and those without, the client may accidentally be able to access
resources belonging to the resource owner. resources belonging to the resource owner.
This attack potentially affects not only implementations using This attack potentially affects not only implementations using
[RFC9068], but also similar, bespoke solutions. [RFC9068], but also similar, bespoke solutions.
4.15.1. Countermeasures 4.15.1. Countermeasures
Authorization servers SHOULD NOT allow clients to influence their Authorization servers SHOULD NOT allow clients to influence their
client_id or any claim that could cause confusion with a genuine client_id or any other claim that could cause confusion with a
resource owner if a common namespace for client IDs and user genuine resource owner if a common namespace for client IDs and user
identifiers exists, such as in the sub claim shown above. Where this identifiers exists, such as in the sub claim example from [RFC9068]
cannot be avoided, authorization servers MUST provide other means for shown in Section 4.15 above. Where this cannot be avoided,
the resource server to distinguish between the two types of access authorization servers MUST provide other means for the resource
tokens. server to distinguish between the two types of access tokens.
4.16. Clickjacking 4.16. Clickjacking
As described in Section 4.4.1.9 of [RFC6819], the authorization As described in Section 4.4.1.9 of [RFC6819], the authorization
request is susceptible to clickjacking attacks, also called user request is susceptible to clickjacking attacks, also called user
interface redressing. In such an attack, an attacker embeds the interface redressing. In such an attack, an attacker embeds the
authorization endpoint user interface in an innocuous context. A authorization endpoint user interface in an innocuous context. A
user believing to interact with that context, for example, by user believing to interact with that context, for example, by
clicking on buttons, inadvertently interacts with the authorization clicking on buttons, inadvertently interacts with the authorization
endpoint user interface instead. The opposite can be achieved as endpoint user interface instead. The opposite can be achieved as
skipping to change at line 2142 skipping to change at line 2150
code: "ABC", code: "ABC",
state: "123" state: "123"
}, },
"*" // any website in the opener window can receive the message "*" // any website in the opener window can receive the message
) )
4.17.1.2. Insufficient URI Validation 4.17.1.2. Insufficient URI Validation
When sending the authorization response or token response via When sending the authorization response or token response via
postMessage, the authorization server may not check the receiver postMessage, the authorization server may not check the receiver
origin against the redirect URI and instead, for example, may send origin against the redirection URI and instead, for example, may send
the response to an origin provided by an attacker. This is analogous the response to an origin provided by an attacker. This is analogous
to the attack described in Section 4.1. to the attack described in Section 4.1.
window.opener.postMessage( window.opener.postMessage(
{ {
code: "ABC", code: "ABC",
state: "123" state: "123"
}, },
"https://attacker.example" // attacker-provided value "https://attacker.example" // attacker-provided value
) )
skipping to change at line 2286 skipping to change at line 2294
and Certificate-Bound Access Tokens", RFC 8705, and Certificate-Bound Access Tokens", RFC 8705,
DOI 10.17487/RFC8705, February 2020, DOI 10.17487/RFC8705, February 2020,
<https://www.rfc-editor.org/info/rfc8705>. <https://www.rfc-editor.org/info/rfc8705>.
[RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
2021, <https://www.rfc-editor.org/info/rfc9068>. 2021, <https://www.rfc-editor.org/info/rfc9068>.
7.2. Informative References 7.2. Informative References
[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", arXiv:1508.04324v2,
DOI 10.48550/arXiv.1508.04324, 7 January 2016,
<https://arxiv.org/abs/1508.04324v2/>.
[arXiv.1601.01229]
Fett, D., Küsters, R., and G. Schmitz, "A Comprehensive
Formal Security Analysis of OAuth 2.0", arXiv:1601.01229,
DOI 10.48550/arXiv.1601.01229, 6 January 2016,
<https://arxiv.org/abs/1601.01229/>.
[arXiv.1704.08539]
Fett, D., Küsters, R., and G. Schmitz, "The Web SSO
Standard OpenID Connect: In-Depth Formal Security Analysis
and Security Guidelines", arXiv:1704.08539,
DOI 10.48550/arXiv.1704.08539, 27 April 2017,
<https://arxiv.org/abs/1704.08539/>.
[arXiv.1901.11520]
Fett, D., Hosseyni, P., and R. Küsters, "An Extensive
Formal Security Analysis of the OpenID Financial-grade
API", arXiv:1901.11520, DOI 10.48550/arXiv.1901.11520, 31
January 2019, <https://arxiv.org/abs/1901.11520/>.
[bug.chromium]
"Referer header includes URL fragment when opening link
using New Tab", Chromium Issue Tracker, Issue ID:
40076763, <https://issues.chromium.org/issues/40076763>.
[JWT-ENCODED-STATE] [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", Work claims in the OAuth 2 state parameter using a JWT", Work
in Progress, Internet-Draft, draft-bradley-oauth-jwt- in Progress, Internet-Draft, draft-bradley-oauth-jwt-
encoded-state-09, 4 November 2018, encoded-state-09, 4 November 2018,
<https://datatracker.ietf.org/doc/html/draft-bradley- <https://datatracker.ietf.org/doc/html/draft-bradley-
oauth-jwt-encoded-state-09>. oauth-jwt-encoded-state-09>.
[TOKEN-BINDING]
Jones, M., Campbell, B., Bradley, J., and W. Denniss,
"OAuth 2.0 Token Binding", Work in Progress, Internet-
Draft, draft-ietf-oauth-token-binding-08, 19 October 2018,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
token-binding-08>.
[OAUTH-V2.1] [OAUTH-V2.1]
Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1 Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1
Authorization Framework", Work in Progress, Internet- Authorization Framework", Work in Progress, Internet-
Draft, draft-ietf-oauth-v2-1-11, 14 May 2024, Draft, draft-ietf-oauth-v2-1-12, 15 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth- <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
v2-1-11>. v2-1-12>.
[OAuth.Post] [OAuth.Post]
Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response
Mode", The OpenID Foundation, 27 April 2015, Mode", The OpenID Foundation, 27 April 2015,
<https://openid.net/specs/oauth-v2-form-post-response- <https://openid.net/specs/oauth-v2-form-post-response-
mode-1_0.html>. mode-1_0.html>.
[OAuth.Responses] [OAuth.Responses]
de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M.
Jones, "OAuth 2.0 Multiple Response Type Encoding Jones, "OAuth 2.0 Multiple Response Type Encoding
skipping to change at line 2340 skipping to change at line 2372
OpenID Foundation, 15 December 2023, OpenID Foundation, 15 December 2023,
<https://openid.net/specs/openid-connect-discovery- <https://openid.net/specs/openid-connect-discovery-
1_0.html>. 1_0.html>.
[OpenID.JARM] [OpenID.JARM]
Lodderstedt, T. and B. Campbell, "Financial-grade API: JWT Lodderstedt, T. and B. Campbell, "Financial-grade API: JWT
Secured Authorization Response Mode for OAuth 2.0 (JARM)", Secured Authorization Response Mode for OAuth 2.0 (JARM)",
The OpenID Foundation, 17 October 2018, The OpenID Foundation, 17 October 2018,
<https://openid.net/specs/openid-financial-api-jarm.html>. <https://openid.net/specs/openid-financial-api-jarm.html>.
[owasp.redir]
OWASP Foundation, "Unvalidated Redirects and Forwards
Cheat Sheet", OWASP Cheat Sheet Series,
<https://cheatsheetseries.owasp.org/cheatsheets/
Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html>.
[research.cmu]
Chen, E., Pei, Y., Chen, S., Tian, Y., Kotcher, R., and P.
Tague, "OAuth Demystified for Mobile Application
Developers", CCS '14: Proceedings of the 2014 ACM SIGSAC
Conference on Computer and Communications Security, pp.
892-903, DOI 10.1145/2660267.2660323, November 2014,
<https://www.microsoft.com/en-us/research/wp-
content/uploads/2016/02/OAuthDemystified.pdf>.
[research.jcs_14]
Bansal, C., Bhargavan, K., Delignat-Lavaud, A., and S.
Maffeis, "Discovering concrete attacks on website
authorization by formal analysis", Journal of Computer
Security, vol. 22, no. 4, pp. 601-657, DOI 10.3233/JCS-
140503, 23 April 2014,
<https://www.doc.ic.ac.uk/~maffeis/papers/jcs14.pdf>.
[research.rub]
Jannett, L., Mladenov, V., Mainka, C., and J. Schwenk,
"DISTINCT: Identity Theft using In-Browser Communications
in Dual-Window Single Sign-On", CCS '22: Proceedings of
the 2022 ACM SIGSAC Conference on Computer and
Communications Security, DOI 10.1145/3548606.3560692, 7
November 2022,
<https://dl.acm.org/doi/pdf/10.1145/3548606.3560692>.
[research.rub2]
Fries, C., "Security Analysis of Real-Life OpenID Connect
Implementations", Master's thesis, Ruhr-Universität Bochum
(RUB), 20 December 2020,
<https://www.nds.rub.de/media/ei/arbeiten/2021/05/03/
masterthesis.pdf>.
[research.ubc]
Sun, S.-T. and K. Beznosov, "The Devil is in the
(Implementation) Details: An Empirical Analysis of OAuth
SSO Systems", Proceedings of the 2012 ACM conference on
Computer and communications security (CCS '12), pp.
378-390, DOI 10.1145/2382196.2382238, October 2012,
<https://css.csail.mit.edu/6.858/2012/readings/oauth-
sso.pdf>.
[research.udel]
Liu, D., Hao, S., and H. Wang, "All Your DNS Records Point
to Us: Understanding the Security Threats of Dangling DNS
Records", CCS '16: Proceedings of the 2016 ACM SIGSAC
Conference on Computer and Communications Security, pp.
1414-1425, DOI 10.1145/2976749.2978387, 24 October 2016,
<https://dl.acm.org/doi/pdf/10.1145/2976749.2978387>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015, RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://www.rfc-editor.org/info/rfc7591>. <https://www.rfc-editor.org/info/rfc7591>.
skipping to change at line 2397 skipping to change at line 2485
[RFC9440] Campbell, B. and M. Bishop, "Client-Cert HTTP Header [RFC9440] Campbell, B. and M. Bishop, "Client-Cert HTTP Header
Field", RFC 9440, DOI 10.17487/RFC9440, July 2023, Field", RFC 9440, DOI 10.17487/RFC9440, July 2023,
<https://www.rfc-editor.org/info/rfc9440>. <https://www.rfc-editor.org/info/rfc9440>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/info/rfc9449>. September 2023, <https://www.rfc-editor.org/info/rfc9449>.
[TOKEN-BINDING]
Jones, M., Campbell, B., Bradley, J., and W. Denniss,
"OAuth 2.0 Token Binding", Work in Progress, Internet-
Draft, draft-ietf-oauth-token-binding-08, 19 October 2018,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
token-binding-08>.
[W3C.CSP-2] [W3C.CSP-2]
West, M., Barth, A., and D. Veditz, "Content Security West, M., Barth, A., and D. Veditz, "Content Security
Policy Level 2", W3C Recommendation, December 2016, Policy Level 2", W3C Recommendation, December 2016,
<https://www.w3.org/TR/2016/REC-CSP2-20161215/>. Latest <https://www.w3.org/TR/2016/REC-CSP2-20161215/>. Latest
version available at <https://www.w3.org/TR/CSP2/>. version available at <https://www.w3.org/TR/CSP2/>.
[W3C.webappsec-referrer-policy]
Eisinger, J. and E. Stark, "Referrer Policy", 26 January
2017,
<https://www.w3.org/TR/2017/CR-referrer-policy-20170126/>.
Latest version available at
<https://www.w3.org/TR/referrer-policy/>.
[W3C.WebAuthn] [W3C.WebAuthn]
Hodges, J., Jones, J.C., Jones, M.B., Kumar, A., and E. Hodges, J., Jones, J.C., Jones, M.B., Kumar, A., and E.
Lundberg, "Web Authentication: An API for accessing Public Lundberg, "Web Authentication: An API for accessing Public
Key Credentials Level 2", W3C Recommendation, 8 April Key Credentials Level 2", W3C Recommendation, 8 April
2021, 2021,
<https://www.w3.org/TR/2021/REC-webauthn-2-20210408/>. <https://www.w3.org/TR/2021/REC-webauthn-2-20210408/>.
Latest version available at Latest version available at
<https://www.w3.org/TR/webauthn-2/>. <https://www.w3.org/TR/webauthn-2/>.
[W3C.WebCrypto] [W3C.WebCrypto]
Watson, M., Ed., "Web Cryptography API", W3C Watson, M., Ed., "Web Cryptography API", W3C
Recommendation, 26 January 2017, Recommendation, 26 January 2017,
<https://www.w3.org/TR/2017/REC-WebCryptoAPI-20170126/>. <https://www.w3.org/TR/2017/REC-WebCryptoAPI-20170126/>.
Latest version available at Latest version available at
<https://www.w3.org/TR/WebCryptoAPI/>. <https://www.w3.org/TR/WebCryptoAPI/>.
[W3C.webappsec-referrer-policy]
Eisinger, J. and E. Stark, "Referrer Policy", 26 January
2017,
<https://www.w3.org/TR/2017/CR-referrer-policy-20170126/>.
Latest version available at
<https://www.w3.org/TR/referrer-policy/>.
[WHATWG.CORS] [WHATWG.CORS]
WHATWG, "CORS protocol", Fetch: Living Standard, WHATWG, "CORS protocol", Fetch: Living Standard,
Section 3.2, 17 June 2024, Section 3.2, 17 June 2024,
<https://fetch.spec.whatwg.org/#http-cors-protocol>. <https://fetch.spec.whatwg.org/#http-cors-protocol>.
[WHATWG.postmessage_api] [WHATWG.postmessage_api]
WHATWG, "Cross-document messaging", HTML: Living Standard, WHATWG, "Cross-document messaging", HTML: Living Standard,
Section 9.3, 19 August 2024, Section 9.3, 19 August 2024,
<https://html.spec.whatwg.org/multipage/web- <https://html.spec.whatwg.org/multipage/web-
messaging.html#web-messaging>. messaging.html#web-messaging>.
[arXiv.1508.04324v2] Acknowledgements
Mladenov, V., Mainka, C., and J. Schwenk, "On the security
of modern Single Sign-On Protocols: Second-Order
Vulnerabilities in OpenID Connect", arXiv:1508.04324v2,
DOI 10.48550/arXiv.1508.04324, 7 January 2016,
<https://arxiv.org/abs/1508.04324v2/>.
[arXiv.1601.01229]
Fett, D., Küsters, R., and G. Schmitz, "A Comprehensive
Formal Security Analysis of OAuth 2.0", arXiv:1601.01229,
DOI 10.48550/arXiv.1601.01229, 6 January 2016,
<https://arxiv.org/abs/1601.01229/>.
[arXiv.1704.08539]
Fett, D., Küsters, R., and G. Schmitz, "The Web SSO
Standard OpenID Connect: In-Depth Formal Security Analysis
and Security Guidelines", arXiv:1704.08539,
DOI 10.48550/arXiv.1704.08539, 27 April 2017,
<https://arxiv.org/abs/1704.08539/>.
[arXiv.1901.11520]
Fett, D., Hosseyni, P., and R. Küsters, "An Extensive
Formal Security Analysis of the OpenID Financial-grade
API", arXiv:1901.11520, DOI 10.48550/arXiv.1901.11520, 31
January 2019, <https://arxiv.org/abs/1901.11520/>.
[bug.chromium]
"Referer header includes URL fragment when opening link
using New Tab", Chromium Issue Tracker, Issue ID:
40076763, <https://issues.chromium.org/issues/40076763>.
[owasp.redir]
OWASP Foundation, "Unvalidated Redirects and Forwards
Cheat Sheet", OWASP Cheat Sheet Series,
<https://cheatsheetseries.owasp.org/cheatsheets/
Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html>.
[research.cmu]
Chen, E., Pei, Y., Chen, S., Tian, Y., Kotcher, R., and P.
Tague, "OAuth Demystified for Mobile Application
Developers", November 2014,
<https://css.csail.mit.edu/6.858/2012/readings/oauth-
sso.pdf>.
[research.jcs_14]
Bansal, C., Bhargavan, K., Delignat-Lavaud, A., and S.
Maffeis, "Discovering concrete attacks on website
authorization by formal analysis", Journal of Computer
Security, vol. 22, no. 4, pp. 601-657, DOI 10.3233/JCS-
140503, 23 April 2014,
<https://www.doc.ic.ac.uk/~maffeis/papers/jcs14.pdf>.
[research.rub]
Jannett, L., Mladenov, V., Mainka, C., and J. Schwenk,
"DISTINCT: Identity Theft using In-Browser Communications
in Dual-Window Single Sign-On", CCS '22: Proceedings of
the 2022 ACM SIGSAC Conference on Computer and
Communications Security, DOI 10.1145/3548606.3560692, 7
November 2022,
<https://dl.acm.org/doi/pdf/10.1145/3548606.3560692>.
[research.rub2]
Fries, C., "Security Analysis of Real-Life OpenID Connect
Implementations", Master's thesis, Ruhr-Universität Bochum
(RUB), 20 December 2020,
<https://www.nds.rub.de/media/ei/arbeiten/2021/05/03/
masterthesis.pdf>.
[research.ubc]
Sun, S.-T. and K. Beznosov, "The Devil is in the
(Implementation) Details: An Empirical Analysis of OAuth
SSO Systems", Proceedings of the 2012 ACM conference on
Computer and communications security (CCS '12), pp.
378-390, DOI 10.1145/2382196.2382238, October 2012,
<https://css.csail.mit.edu/6.858/2012/readings/oauth-
sso.pdf>.
[research.udel]
Liu, D., Hao, S., and H. Wang, "All Your DNS Records Point
to Us: Understanding the Security Threats of Dangling DNS
Records", CCS '16: Proceedings of the 2016 ACM SIGSAC
Conference on Computer and Communications Security, pp.
1414-1425, DOI 10.1145/2976749.2978387, 24 October 2016,
<https://dl.acm.org/doi/pdf/10.1145/2976749.2978387>.
Appendix A. Acknowledgements
We would like to thank Brock Allen, Annabelle Richard Backman, We would like to thank Brock Allen, Annabelle Richard Backman,
Dominick Baier, Vittorio Bertocci, Brian Campbell, Bruno Crispo, Dominick Baier, Vittorio Bertocci, Brian Campbell, Bruno Crispo,
William Dennis, George Fletcher, Matteo Golinelli, Dick Hardt, Joseph William Dennis, George Fletcher, Matteo Golinelli, Dick Hardt, Joseph
Heenan, Pedram Hosseyni, Phil Hunt, Tommaso Innocenti, Louis Jannett, Heenan, Pedram Hosseyni, Phil Hunt, Tommaso Innocenti, Louis Jannett,
Jared Jennings, Michael B. Jones, Engin Kirda, Konstantin Lapine, Jared Jennings, Michael B. Jones, Engin Kirda, Konstantin Lapine,
Neil Madden, Christian Mainka, Jim Manico, Nov Matake, Doug McDorman, Neil Madden, Christian Mainka, Jim Manico, Nov Matake, Doug McDorman,
Karsten Meyer zu Selhausen, Ali Mirheidari, Vladislav Mladenov, Kaan Karsten Meyer zu Selhausen, Ali Mirheidari, Vladislav Mladenov, Kaan
Onarioglu, Aaron Parecki, Michael Peck, Johan Peeters, Nat Sakimura, Onarioglu, Aaron Parecki, Michael Peck, Johan Peeters, Nat Sakimura,
Guido Schmitz, Jörg Schwenk, Rifaat Shekh-Yusef, Travis Spencer, Guido Schmitz, Jörg Schwenk, Rifaat Shekh-Yusef, Travis Spencer,
 End of changes. 78 change blocks. 
249 lines changed or deleted 259 lines changed or added

This html diff was produced by rfcdiff 1.48.