<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl"
<!--[rfced] This document has been assigned a new BCP number
(BCP 240). Please let us know if this is not correct (i.e., it should
be part of an existing BCP). See the complete list of BCPs here:
https://www.rfc-editor.org/bcps
We note that none of the RFCs being updated (RFCs 6749, 6750,
and 6819) were BCPs.
-->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-oauth-security-topics-29" number="9700" consensus="true" submissionType="IETF" category="bcp" xml:lang="en" updates="6749, 6750, 6819" indexInclude="true" tocDepth="4"> obsoletes="" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="false">
<!--[rfced] Regarding the RFC's title
a) May we update the title as follows for clarity?
Original: OAuth 2.0 Security Best Current Practice
Perhaps: Best Current Practice for OAuth 2.0 Security
b) The abbreviated title (which appears in the PDF file) may remain as is
or be updated similarly. Please let us know your preference.
Original: OAuth 2.0 Security BCP
Perhaps: BCP for OAuth 2.0 Security
-->
<front>
<title abbrev="OAuth 2.0 Security BCP">OAuth 2.0 Security Best Current Practice</title><seriesInfo value="draft-ietf-oauth-security-topics-29" stream="IETF" status="bcp" name="Internet-Draft"/>
Practice</title>
<seriesInfo name="RFC" value="9700"/>
<seriesInfo name="BCP" value="240"/>
<author initials="T." surname="Lodderstedt" fullname="Torsten Lodderstedt"><organization>SPRIND</organization><address><postal><street/>
</postal><email>torsten@lodderstedt.net</email>
</address></author><author Lodderstedt">
<organization>SPRIND</organization>
<address>
<email>torsten@lodderstedt.net</email>
</address>
</author>
<author initials="J." surname="Bradley" fullname="John Bradley"><organization>Yubico</organization><address><postal><street/>
</postal><email>ve7jtb@ve7jtb.com</email>
</address></author><author Bradley">
<organization>Yubico</organization>
<address>
<email>ve7jtb@ve7jtb.com</email>
</address>
</author>
<author initials="A." surname="Labunets" fullname="Andrey Labunets"><organization>Independent Researcher</organization><address><postal><street/>
</postal><email>isciurus@gmail.com</email>
</address></author><author Labunets">
<organization>Independent Researcher</organization>
<address>
<email>isciurus@gmail.com</email>
</address>
</author>
<author initials="D." surname="Fett" fullname="Daniel Fett"><organization>Authlete</organization><address><postal><street/>
</postal><email>mail@danielfett.de</email>
</address></author><date/>
<area>Security</area>
<workgroup>Web Authorization Protocol</workgroup>
<keyword>security</keyword>
<keyword>oauth2</keyword>
<keyword>best current practice</keyword> Fett">
<organization>Authlete</organization>
<address>
<email>mail@danielfett.de</email>
</address>
</author>
<date year="2024" month="November"/>
<area>SEC</area>
<workgroup>oauth</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract>
<t>This document describes best current security practice for OAuth 2.0. It updates
and extends the threat model and security advice given in RFC RFCs 6749,
RFC 6750, and RFC 6819 to incorporate practical experiences gathered since
OAuth 2.0 was published and covers new threats relevant due to the broader
application of OAuth 2.0. Further, it deprecates some modes of operation that are
deemed less secure or even insecure.</t>
</abstract>
<note title="Discussion Venues" removeInRFC="true">
<t>Discussion of this document takes place on the
Web Authorization Protocol Working Group mailing list (oauth@ietf.org),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/oauth/"/>.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/oauthstuff/draft-ietf-oauth-security-topics"/>.</t>
</note>
</front>
<middle>
<section anchor="Introduction"><name>Introduction</name>
<t>Since its publication in <xref target="RFC6749"/> and <xref target="RFC6750"/>, OAuth 2.0 (referred to as simply "OAuth" in the following) this document) has gained massive traction in the market
and became the standard for API protection and the basis for federated
login using OpenID Connect <xref target="OpenID.Core"/>. While OAuth is used in a
variety of scenarios and different kinds of deployments, the following
challenges can be observed:</t>
<ul>
<li><t>OAuth implementations are being attacked through known implementation
weaknesses and anti-patterns (i.e., well-known patterns that are considered
insecure). Although most of these threats are discussed in the OAuth 2.0
Threat Model and Security Considerations <xref target="RFC6819"/>, continued exploitation
demonstrates a need for more specific recommendations, easier to implement
mitigations, and more defense in depth.</t>
</li>
<li><t>OAuth is being used in environments with higher security requirements than
considered initially, such as Open Banking, open banking, eHealth, eGovernment, and
Electronic Signatures.
electronic signatures. Those use cases call for stricter guidelines and
additional protection.</t>
</li>
<li><t>OAuth is being used in much more dynamic setups than originally anticipated,
creating new challenges with respect to security. Those challenges go beyond
the original scope of <xref target="RFC6749"/>, <xref target="RFC6750"/>, and <xref target="RFC6819"/>.</t>
<t>OAuth initially assumed static relationships between clients,
authorization servers, and resource servers. The URLs of the servers were
known to the client at deployment time and built an anchor for the
trust relationships among those parties. The validation of whether the
client is talking to a legitimate server was based on TLS server
authentication (see <xref target="RFC6819"/>, Section 4.5.4). target="RFC6819" sectionFormat="of" section="4.5.4"/>). With the increasing
adoption of OAuth, this simple model dissolved and, in several
scenarios, was replaced by a dynamic establishment of the relationship
between clients on one side and the authorization and resource servers
of a particular deployment on the other side. This way, the same
client could be used to access services of different providers (in
case of standard APIs, such as e-mail email or OpenID Connect) or serve as a
front end to a particular tenant in a multi-tenant environment.
Extensions of OAuth, such as the OAuth 2.0 Dynamic Client Registration
Protocol <xref target="RFC7591"/> and OAuth 2.0 Authorization Server Metadata
<xref target="RFC8414"/> were developed to support the use of OAuth in
dynamic scenarios.</t>
</li>
<li><t>Technology has changed. For example, the way browsers treat fragments when
redirecting requests has changed, and with it, the implicit grant's
underlying security model.</t>
</li>
</ul>
<t>This document provides updated security recommendations to address these
challenges. It introduces new requirements beyond those defined in existing
specifications such as OAuth 2.0 <xref target="RFC6749"/> and OpenID Connect <xref target="OpenID.Core"/>
and deprecates some modes of operation that are deemed less secure or even
insecure. However, this document does not supplant the security advice given in
<xref target="RFC6749"/>, <xref target="RFC6750"/>, and <xref target="RFC6819"/>, but complements those documents.</t>
<t>Naturally, not all existing ecosystems and implementations are
compatible with the new requirements requirements, and following the best practices described in
this document may break interoperability. Nonetheless, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that
implementers upgrade their implementations and ecosystems as soon as feasible.</t>
<t>OAuth 2.1, under developement development as <xref target="I-D.ietf-oauth-v2-1"/>, will incorporate
security recommendations from this document.</t>
<section anchor="structure"><name>Structure</name>
<t>The remainder of this document is organized as follows: The next section <xref target="recommendations"/>
summarizes the most important best practices for every OAuth implementor.
Afterwards,
<xref target="secmodel"/> presents the updated OAuth attacker model model. <xref target="attacks_and_mitigations"/> is presented. Subsequently, a
detailed analysis of the threats and implementation issues that can be found in
the wild today is given (at the time of writing) along with a discussion of potential countermeasures.</t>
</section>
<section anchor="conventions-and-terminology"><name>Conventions and Terminology</name>
<t>The
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
interpreted as described in BCP 14 BCP 14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.</t> here.
</t>
<t>This specification uses the terms "access token", "authorization
endpoint", "authorization grant", "authorization server", "client",
"client identifier" (client ID), "protected resource", "refresh
token", "resource owner", "resource server", and "token endpoint"
defined by OAuth 2.0 <xref target="RFC6749"/>.</t>
<t>An "open redirector" is an endpoint on a web server that forwards a user’s user's
browser to an arbitrary URI obtained from a query parameter.</t>
</section>
</section>
<section anchor="recommendations"><name>Best Practices</name>
<t>This section describes the core set of security mechanisms and measures that
are considered to be best practices at the time of writing. Details
about these security mechanisms and measures (including detailed attack
descriptions) and requirements for less commonly used options are provided in
<xref target="attacks_and_mitigations"/>.</t>
<section anchor="rec_redirect"><name>Protecting Redirect-Based Flows</name>
<!--[rfced] This document mostly uses "redirect URI".
Would you like to change the instances of "redirection URI"
for consistency? Or, is there is there a difference in meaning?
In the original:
redirect URI (58 instances) vs. redirection URI (1 instance)
redirect URL (2 instances) vs. redirection URL (2 instances)
-->
<t>When comparing client redirect URIs against pre-registered URIs, authorization
servers MUST <bcp14>MUST</bcp14> utilize exact string matching except for port numbers in
<tt>localhost</tt> redirection URIs of native apps (see <xref target="iuv_countermeasures"/>). This
measure contributes to the prevention of leakage of authorization codes and
access tokens (see <xref target="insufficient_uri_validation"/>). It can also help to detect
mix-up attacks (see <xref target="mix_up"/>).</t>
<t>Clients and authorization servers MUST NOT <bcp14>MUST NOT</bcp14> expose URLs that forward the user's browser to
arbitrary URIs obtained from a query parameter (open redirectors) as
described in <xref target="open_redirection"/>. Open redirectors can enable
exfiltration of authorization codes and access tokens.</t>
<t>Clients MUST <bcp14>MUST</bcp14> prevent Cross-Site Request Forgery (CSRF). In this
context, CSRF refers to requests to the redirection endpoint that do
not originate at the authorization server, but at a malicious third party
(see Section 4.4.1.8. of <xref target="RFC6819"/> target="RFC6819" sectionFormat="of" section="4.4.1.8"/> for details). Clients that have
ensured that the authorization server supports Proof Key for Code Exchange (PKCE, (PKCE) <xref target="RFC7636"/>) MAY target="RFC7636"/> <bcp14>MAY</bcp14>
rely on the CSRF protection provided by PKCE. In OpenID Connect flows,
the <tt>nonce</tt> parameter provides CSRF protection. Otherwise, one-time
use CSRF tokens carried in the <tt>state</tt> parameter that are securely
bound to the user agent MUST <bcp14>MUST</bcp14> be used for CSRF protection (see
<xref target="csrf_countermeasures"/>).</t>
<t>When an OAuth client can interact with more than one authorization server, a
defense against mix-up attacks (see <xref target="mix_up"/>) is REQUIRED. <bcp14>REQUIRED</bcp14>. To this end, clients
SHOULD</t>
<bcp14>SHOULD</bcp14></t>
<ul spacing="compact">
<li>use the <tt>iss</tt> parameter as a countermeasure according to
<xref target="RFC9207"/>, or</li>
<!--[rfced] What does "it" refer to here? The iss value or the response?
Original:
* use an alternative countermeasure based on an iss value in the
authorization response (such as the iss Claim in the ID Token in
[OpenID.Core] or in [OpenID.JARM] responses), processing it as
described in [RFC9207].
Perhaps:
* use an alternative countermeasure based on an iss value in the
authorization response (such as the iss claim in the ID Token in
[OpenID.Core] or in [OpenID.JARM] responses), processing that value
as described in [RFC9207].
Side note re: claim vs. Claim.
FYI, the one instance of "iss Claim" has been changed to "iss claim".
This is in keeping with how it appears in RFC 9207, as well as
how other claims appear in this document (sub claim, aud claim).
(However, we see the capitalized from is mostly used in [OpenID.Core].)
-->
<li>use an alternative countermeasure based on an <tt>iss</tt> value in the
authorization response (such as the <tt>iss</tt> Claim claim in the ID Token in
<xref target="OpenID.Core"/> or in <xref target="OpenID.JARM"/> responses), processing it as described in
<xref target="RFC9207"/>.</li>
</ul>
<t>In the absence of these options, clients MAY <bcp14>MAY</bcp14> instead use distinct redirect URIs
to identify authorization endpoints and token endpoints, as described in
<xref target="mixupcountermeasures"/>.</t>
<t>An authorization server that redirects a request potentially containing user credentials
MUST
<bcp14>MUST</bcp14> avoid forwarding these user credentials accidentally (see
<xref target="redirect_307"/> for details).</t>
<section anchor="ac"><name>Authorization Code Grant</name>
<t>Clients MUST <bcp14>MUST</bcp14> prevent authorization code
injection attacks (see <xref target="code_injection"/>) and misuse of authorization codes using one of the following options:</t>
<ul spacing="compact">
<li>Public clients MUST <bcp14>MUST</bcp14> use PKCE <xref target="RFC7636"/> to this end, as motivated in
<xref target="pkce_as_injection_protection"/>.</li>
<li>For confidential clients, the use of PKCE <xref target="RFC7636"/> is RECOMMENDED, <bcp14>RECOMMENDED</bcp14>, as it
provides strong protection against misuse and injection of authorization
codes as described in <xref target="pkce_as_injection_protection"/> and, target="pkce_as_injection_protection"/>. Also, as a side-effect, side effect,
it prevents CSRF even in the presence of strong attackers as described in
<xref target="csrf_countermeasures"/>.</li>
<li>With additional precautions, described in <xref target="nonce_as_injection_protection"/>,
confidential OpenID Connect <xref target="OpenID.Core"/> clients MAY <bcp14>MAY</bcp14> use the <tt>nonce</tt> parameter and the
respective Claim in the ID Token instead.</li>
</ul>
<t>In any case, the PKCE challenge or OpenID Connect <tt>nonce</tt> MUST <bcp14>MUST</bcp14> be
transaction-specific and securely bound to the client and the user agent in
which the transaction was started.
Authorization servers are encouraged to make a reasonable effort at detecting and
preventing the use of constant values for the PKCE challenge or OpenID Connect <tt>nonce</tt> values.</t> <tt>nonce</tt>.</t>
<t>Note: Although PKCE was designed as a mechanism to protect native
apps, this advice applies to all kinds of OAuth clients, including web
applications.</t>
<t>When using PKCE, clients SHOULD <bcp14>SHOULD</bcp14> use PKCE code challenge methods that
do not expose the PKCE verifier in the authorization request.
Otherwise, attackers that can read the authorization request (cf.
Attacker A4 attacker <xref target="read_request" format="none">(A4)</xref> in <xref target="secmodel"/>) can break the security provided
by PKCE. Currently, <tt>S256</tt> is the only such method.</t>
<t>Authorization servers MUST <bcp14>MUST</bcp14> support PKCE <xref target="RFC7636"/>.</t>
<t>If a client sends a valid PKCE <xref target="RFC7636"/> <tt>code_challenge</tt> parameter in the
authorization request, the authorization server MUST <bcp14>MUST</bcp14> enforce the correct usage
of <tt>code_verifier</tt> at the token endpoint.</t>
<t>Authorization servers MUST <bcp14>MUST</bcp14> mitigate PKCE Downgrade Attacks downgrade attacks by ensuring that a
token request containing a <tt>code_verifier</tt> parameter is accepted only if a
<tt>code_challenge</tt> parameter was present in the authorization request, request; see
<xref target="pkce_downgrade_countermeasures"/> for details.</t>
<t>Authorization servers MUST <bcp14>MUST</bcp14> provide a way to detect their support for
PKCE. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> for authorization servers to publish the element
<tt>code_challenge_methods_supported</tt> in their Authorization Server Metadata (<xref target="RFC8414"/>) <xref target="RFC8414"/>
containing the supported PKCE challenge methods (which can be used by
the client to detect PKCE support). Authorization servers MAY <bcp14>MAY</bcp14> instead provide a
deployment-specific way to ensure or determine PKCE support by the authorization server.</t>
</section>
<!--[rfced] Section 2.1.2: response type "token" vs. response type code
These are formatted inconsistently - quotation marks vs. using <tt>.
Which do you prefer for consistent handling?
-->
<section anchor="implicit_grant_recommendation"><name>Implicit Grant</name>
<t>The implicit grant (response type "token") and other response types
causing the authorization server to issue access tokens in the
authorization response are vulnerable to access token leakage and
access token replay as described in Sections <xref target="insufficient_uri_validation"/>, target="insufficient_uri_validation" format="counter"/>,
<xref target="credential_leakage_referrer"/>, target="credential_leakage_referrer" format="counter"/>, <xref target="browser_history"/>, target="browser_history" format="counter"/>, and
<xref target="access_token_injection"/>.</t> target="access_token_injection" format="counter"/>.</t>
<t>Moreover, no standardized method for sender-constraining exists to
bind access tokens to a specific client (as recommended in
<xref target="token_replay_prevention"/>) when the access tokens are issued in the
authorization response. This means that an attacker can use the leaked or stolen
access token at a resource endpoint.</t>
<t>In order to avoid these issues, clients SHOULD NOT <bcp14>SHOULD NOT</bcp14> use the implicit
grant (response type "token") or other response types issuing
access tokens in the authorization response, unless access token injection
in the authorization response is prevented and the aforementioned token leakage
vectors are mitigated.</t>
<t>Clients SHOULD <bcp14>SHOULD</bcp14> instead use the response type <tt>code</tt> (i.e., authorization
code grant type) as specified in <xref target="ac"/> or any other response type that
causes the authorization server to issue access tokens in the token
response, such as the <tt>code id_token</tt> response type. This allows the
authorization server to detect replay attempts by attackers and
generally reduces the attack surface since access tokens are not
exposed in URLs. It also allows the authorization server to
sender-constrain the issued tokens (see next section).</t> <xref target="token_replay_prevention"/>.</t>
</section>
</section>
<section anchor="token_replay_prevention"><name>Token Replay Prevention</name>
<section anchor="access-tokens"><name>Access Tokens</name>
<t>A sender-constrained access token scopes the applicability of an access
token to a certain sender. This sender is obliged to demonstrate knowledge
of a certain secret as a prerequisite for the acceptance of that token at
the recipient (e.g., a resource server).</t>
<t>Authorization and resource servers SHOULD <bcp14>SHOULD</bcp14> use mechanisms for sender-constraining
access tokens, such as Mutual TLS for OAuth 2.0 <xref target="RFC8705"/> or OAuth 2.0
Demonstrating Proof of Possession (DPoP) <xref target="RFC9449"/> (see
<xref target="pop_tokens"/>), to prevent misuse of stolen and leaked access tokens.</t>
</section>
<section anchor="refresh-tokens"><name>Refresh Tokens</name>
<t>Refresh tokens for public clients MUST <bcp14>MUST</bcp14> be sender-constrained or use refresh
token rotation as described in <xref target="refresh_token_protection"/>. <xref target="RFC6749"/> already
mandates that refresh tokens for confidential clients can only be used by the
client for which they were issued.</t>
</section>
</section>
<section anchor="access-token-privilege-restriction"><name>Access Token Privilege Restriction</name>
<t>The privileges associated with an access token SHOULD <bcp14>SHOULD</bcp14> be restricted to
the minimum required for the particular application or use case. This
prevents clients from exceeding the privileges authorized by the
resource owner. It also prevents users from exceeding their privileges
authorized by the respective security policy. Privilege restrictions
also help to reduce the impact of access token leakage.</t>
<t>In particular, access tokens SHOULD <bcp14>SHOULD</bcp14> be audience-restricted to a specific resource
server,
server or, if that is not feasible, to a small set of resource servers. To put this into effect, the authorization server associates
the access token with certain resource servers servers, and every resource
server is obliged to verify, for every request, whether the access
token sent with that request was meant to be used for that particular
resource server. If it was not, the resource server MUST <bcp14>MUST</bcp14> refuse to serve the
respective request. The <tt>aud</tt> claim as defined in <xref target="RFC9068"/> MAY <bcp14>MAY</bcp14> be
used to audience-restrict access tokens. Clients and authorization servers MAY <bcp14>MAY</bcp14> utilize the
parameters <tt>scope</tt> or <tt>resource</tt> as specified in <xref target="RFC6749"/> and
<xref target="RFC8707"/>, respectively, to determine the
resource server they want to access.</t>
<t>Additionally, access tokens SHOULD <bcp14>SHOULD</bcp14> be restricted to certain resources
and actions on resource servers or resources. To put this into effect,
the authorization server associates the access token with the
respective resource and actions and every resource server is obliged
to verify, for every request, whether the access token sent with that
request was meant to be used for that particular action on the
particular resource. If not, the resource server must refuse to serve
the respective request. Clients and authorization servers MAY <bcp14>MAY</bcp14> utilize
the parameter <tt>scope</tt> as specified in <xref target="RFC6749"/> and <tt>authorization_details</tt> as specified in <xref target="RFC9396"/> to determine those
resources and/or actions.</t>
</section>
<section anchor="resource-owner-password-credentials-grant"><name>Resource Owner Password Credentials Grant</name>
<!--[rfced] Please clarify; how does the end of this sentence connect to
the first part? Does this result in (a) increased attack surface and
(b) users being trained to enter their credentials?
Original:
Even if the client is benign, this
results in an increased attack surface (credentials can leak in more
places than just the authorization server) and users are trained to
enter their credentials in places other than the authorization
server.
Perhaps:
Even if the client is benign, this
results in an increased attack surface (i.e., credentials can leak in more
places than just the authorization server) and users being trained to
enter their credentials in places other than the authorization
server.
Or:
Even if the client is benign, this
results in an increased attack surface (i.e., credentials can leak in more
places than just the authorization server) and in training users to
enter their credentials in places other than the authorization
server.
-->
<t>The resource owner password credentials grant <xref target="RFC6749"/> MUST NOT <bcp14>MUST NOT</bcp14>
be used. This grant type insecurely exposes the credentials of the resource
owner to the client. Even if the client is benign, this results in an increased
attack surface (credentials can leak in more places than just the authorization server) and users
are trained to enter their credentials in places other than the authorization server.</t>
<t>Furthermore, the resource owner password credentials grant is not designed to
work with two-factor authentication and authentication processes that require
multiple user interaction steps. Authentication with cryptographic credentials
(cf. WebCrypto <xref target="W3C.WebCrypto"/>, WebAuthn <xref target="W3C.WebAuthn"/>) may be impossible
to implement with this grant type, as it is usually bound to a specific web origin.</t>
</section>
<section anchor="client-authentication"><name>Client Authentication</name>
<t>Authorization servers SHOULD <bcp14>SHOULD</bcp14> enforce client authentication if it is feasible, in
the particular deployment, to establish a process for issuance/registration of
credentials for clients and ensuring the confidentiality of those credentials.</t>
<t>It
<!--[rfced] To clarify the text regarding signed JWT, Private Key JWT,
and private_key_jwt, may this sentence be updated as follows?
Original:
It is RECOMMENDED to use asymmetric cryptography for client
authentication, such as mTLS [RFC8705] or signed JWTs ("Private Key
JWT") in accordance with [RFC7521] and [RFC7523] (in [OpenID.Core]
defined as the client authentication method private_key_jwt)
Perhaps:
It is RECOMMENDED to use asymmetric cryptography for client
authentication, such as mTLS [RFC8705] or signed JWTs in accordance
with [RFC7521] and [RFC7523]. (A signed JWT is also called a
"Private Key JWT", and in [OpenID.Core] it is defined as the client
authentication method private_key_jwt.)
-->
<t>It is <bcp14>RECOMMENDED</bcp14> to use asymmetric cryptography for
client authentication, such as mutual TLS (mTLS) <xref target="RFC8705"/> or signed JWTs
("Private Key JWT") in accordance with <xref target="RFC7521"/> and <xref target="RFC7523"/>
(in <xref target="OpenID.Core"/> defined as the client authentication method <tt>private_key_jwt</tt>).
When asymmetric cryptography for client authentication is used, authorization
servers do not need to store sensitive symmetric keys, making these
methods more robust against leakage of keys.</t>
</section>
<section anchor="other_recommendations"><name>Other Recommendations</name>
<t>The use of OAuth Authorization Server Metadata <xref target="RFC8414"/> can help to improve the security of OAuth
deployments:</t>
<ul spacing="compact">
<li>It ensures that security features and other new OAuth features can be enabled
automatically by compliant software libraries.</li>
<li>It reduces chances for misconfigurations, misconfigurations -- for example example, misconfigured endpoint
URLs (that might belong to an attacker) or misconfigured security features.</li>
<li>It can help to facilitate rotation of cryptographic keys and to ensure
cryptographic agility.</li>
</ul>
<t>It is therefore RECOMMENDED <bcp14>RECOMMENDED</bcp14> that authorization servers publish OAuth Authorization Server Metadata according to
<xref target="RFC8414"/> and that clients make use of this Authorization Server Metadata (when available) to configure themselves
when available.</t> themselves.</t>
<!--[rfced] To clarify, may we change "any claim" to "any other claim",
because the first part is seemingly about a "client_id" claim?
Original:
Under the conditions described in Section 4.15.1, authorization
servers SHOULD NOT allow clients to influence their client_id or any
claim that could cause confusion with a genuine resource owner.
Perhaps:
Under the conditions described in Section 4.15.1, authorization
servers SHOULD NOT allow clients to influence their client_id or
any other claim that could cause confusion with a genuine resource
owner.
This also appears in Section 4.15.1:
Original:
Authorization servers SHOULD NOT allow clients to influence their
client_id or any claim that could cause confusion with a genuine
resource owner ...
Perhaps:
Authorization servers SHOULD NOT allow clients to influence their
client_id or any other claim that could cause confusion with a genuine
resource owner ...
-->
<t>Under the conditions described in <xref target="client_impersonating_countermeasures"/>,
authorization servers SHOULD NOT <bcp14>SHOULD NOT</bcp14> allow clients to influence their <tt>client_id</tt> or
any claim that could cause confusion with a genuine resource owner.</t>
<t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to use end-to-end TLS according to <xref target="BCP195"/> between the client and the resource server. If TLS
traffic needs to be terminated at an intermediary, refer to
<xref target="tls_terminating"/> for further security advice.</t>
<t>Authorization responses MUST NOT <bcp14>MUST NOT</bcp14> be transmitted over unencrypted network
connections. To this end, authorization servers MUST NOT <bcp14>MUST NOT</bcp14> allow redirect URIs that use the <tt>http</tt>
scheme except for native clients that use Loopback Interface Redirection loopback interface redirection as
described in <xref target="RFC8252"/>, Section 7.3.</t> target="RFC8252" sectionFormat="of" section="7.3"/>.</t>
<t>If the authorization response is sent with in-browser communication techniques
like postMessage <xref target="WHATWG.postmessage_api"/> instead of HTTP redirects, both the
initiator and receiver of the in-browser message MUST <bcp14>MUST</bcp14> be strictly verified as described
in <xref target="rec_ibc"/>.</t>
<t>To support browser-based clients, endpoints directly accessed by such clients
including the Token Endpoint, Authorization Server Metadata Endpoint, <tt>jwks_uri</tt>
Endpoint, and the Dynamic Client Registration Endpoint MAY <bcp14>MAY</bcp14> support the use of
Cross-Origin Resource Sharing (CORS, (CORS) <xref target="WHATWG.CORS"/>). target="WHATWG.CORS"/>.
<!--[rfced] FYI, "Authorization Endpoint" has been lowercased to match
the statement in Section 1.2 and other usage within this document.
Please review whether there is some intended difference here, as "Authorization
Server Metadata Endpoint" appears in the preceding sentence.
Original:
However, CORS MUST NOT be supported at the
Authorization Endpoint, as the client does not access this endpoint
directly; instead, the client redirects the user agent to it.
Original:
However, CORS MUST NOT be supported at the
authorization endpoint, as the client does not access this endpoint
directly; instead, the client redirects the user agent to it.
-->
However, CORS <bcp14>MUST NOT</bcp14> be
supported at the authorization endpoint, as the client does not access this
endpoint directly; instead, the client redirects the user agent to it.</t>
</section>
</section>
<section anchor="secmodel"><name>The Updated OAuth 2.0 Attacker Model</name>
<t>In <xref target="RFC6819"/>, a threat model is laid out that describes the threats against
which OAuth deployments must be protected. While doing so, <xref target="RFC6819"/> makes
certain assumptions about attackers and their capabilities, i.e., it implicitly
establishes an attacker model. In the following, this attacker model is made
explicit and is updated and expanded to account for the potentially dynamic
relationships involving multiple parties (as described in <xref target="Introduction"/>), to
include new types of attackers attackers, and to define the attacker model more clearly.</t>
<t>The goal of this document is to ensure that the authorization of a resource
owner (with a user agent) at an authorization server and the subsequent usage of
the access token at a resource server is protected, as well as practically
possible, at least against the following attackers:</t>
<ul>
<li><t>(A1) Web Attackers attackers.</t>
<ol type="(A%d)">
<li anchor="web_attackers"><t>Web attackers that can set up and operate an arbitrary number of
network endpoints (besides the "honest" ones) including browsers and
servers. Web attackers may set up web sites websites that are visited by the resource
owner, operate their own user agents, and participate in the protocol.</t>
<t>Web attackers may, in
<t>In particular, web attackers may operate OAuth clients that are registered
at the authorization server, and they may operate their own authorization and
resource servers that can be used (in parallel to the "honest" ones) by the
resource owner and other resource owners.</t>
<t>It must also be assumed that web attackers can lure the user to
navigate their browser to arbitrary attacker-chosen URIs at any time. In practice, this
can be achieved in many ways, for example, by injecting malicious
advertisements into advertisement networks, networks or by sending
legitimate-looking emails.</t>
<t>Web attackers can use their own user credentials to create new
messages as well as any secrets they learned previously. For
example, if a web attacker learns an authorization code of a user
through a misconfigured redirect URI, the web attacker can then
try to redeem that code for an access token.</t>
<t>They cannot, however, read or manipulate messages that are not
targeted towards them (e.g., sent to a URL controlled by a
non-attacker controlled
non-attacker-controlled authorization server).</t>
<!--[rfced] Should the phrase "non-attacker-controlled" be
updated for clarity? Seems it could be misinterpreted as
"controlled by a non-attacker".
Original:
a URL controlled by a non-attacker-controlled authorization server
Perhaps:
a URL controlled by an authorization server that is not
controlled by an attacker
-->
</li>
<li><t>(A2) Network Attackers
<li anchor="network_attackers"><t>Network attackers that additionally have full control over
the network over which protocol participants communicate. They can
eavesdrop on, manipulate, and spoof messages, except when these
are properly protected by cryptographic methods (e.g., TLS).
Network attackers can also block arbitrary messages.</t>
</li>
</ul>
</ol>
<t>While an example for a web attacker would be a customer of an internet
service provider, network attackers could be the internet service
provider itself, an attacker in a public (Wi-Fi) network using ARP
spoofing, or a state-sponsored attacker with access to internet
exchange points, for instance.</t>
<t>The aforementioned attackers (A1) <xref target="web_attackers" format="none">(A1)</xref> and (A2) <xref target="network_attackers" format="none">(A2)</xref> conform to the attacker model that was used in formal analysis
efforts for OAuth <xref target="arXiv.1601.01229"/>. This is a minimal attacker model.
Implementers MUST <bcp14>MUST</bcp14> take into account all possible types of attackers in the
environment of their OAuth implementations. For example, in <xref target="arXiv.1901.11520"/>,
a very strong attacker model is used that includes attackers that have
full control over the token endpoint. This models effects of a
possible misconfiguration of endpoints in the ecosystem, which can be avoided
by using authorization server metadata as described in <xref target="other_recommendations"/>. Such an attacker is therefore not listed here.</t>
<t>However, previous attacks on OAuth have shown that the following types of
attackers are relevant in particular:</t>
<ul>
<li><t>(A3) Attackers
<ol type="(A%d)" start="3">
<li anchor="read_response"><t>Attackers that can read, but not modify, the contents of the
authorization response (i.e., the authorization response can leak
to an attacker).</t>
<t>Examples
<!--[rfced] For the last item in this list ("and the fact that URLs are..."),
it appears to be the flaw that will be exploited rather than an attack. How
may it be rephrased to be parallel to the other items in the list?
Original:
Examples for such attacks include open redirector attacks,
insufficient checking of redirect URIs (see <xref target="insufficient_uri_validation"/>), Section 4.1), problems
existing on mobile operating systems (where different apps can
register themselves on the same URI), mix-up attacks (see
Section 4.4), where the client is tricked into sending credentials
to an attacker-controlled authorization server, and the fact that
URLs are often stored/logged by browsers (history), proxy servers,
and operating systems.
Perhaps (A):
Examples of such attacks include open redirector attacks;
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); mix-up attacks
(see Section 4.4), where the client is tricked into sending
credentials to an attacker-controlled authorization server; and
attacks that make use of URLs that are often stored/logged by
browsers (history), proxy servers, and operating systems.
Or (B): (if separating out the attack vectors)
Examples of such attacks include open redirector attacks and
mix-up attacks (see Section 4.4), where the client is tricked
into sending credentials to an attacker-controlled authorization
server.
Also, this includes attacks that take advantage of:
* 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 that are often stored/logged by browsers (history),
proxy servers, and operating systems.
-->
<t>Examples of such attacks include open redirector attacks; insufficient
checking of redirect URIs (see <xref target="insufficient_uri_validation"/>); problems
existing on mobile operating systems (where different apps can register
themselves on the same URI); mix-up attacks (see <xref target="mix_up"/>), where the
client is tricked into sending credentials to an attacker-controlled authorization server, server; and
the fact that URLs are often stored/logged by browsers (history), proxy
servers, and operating systems.</t>
</li>
<li><t>(A4) Attackers
<li anchor="read_request"><t>Attackers that can read, but not modify, the contents of the
authorization request (i.e., the authorization request can leak,
in the same manner as above, to an attacker).</t>
</li>
<li><t>(A5) Attackers
<li anchor="acquire_token"><t>Attackers that can acquire an access token issued by an authorization server.
<!--[rfced] FYI, we have updated this sentence as follows to use "may"
consistently and to avoid the usage of "social-engineered into".
Original:
For example, a resource server can be
compromised by an attacker, an access token may be sent to an
attacker-controlled resource server due to a misconfiguration, or
a resource owner is social-engineered into using an attacker-
controlled resource server.
Current:
For example, a resource server may be
compromised by an attacker, an access token may be sent to an
attacker-controlled resource server due to a misconfiguration,
or social engineering may be used to get a resource owner to
use an attacker-controlled resource server
Another option: (simply "tricked")
For example, a resource server may be
compromised by an attacker, an access token may be sent to an
attacker-controlled resource server due to a misconfiguration,
or a resource owner may be tricked into using an attacker-
controlled resource server
-->
For
example, a resource server may be compromised by an attacker, an
access token may be sent to an attacker-controlled resource server
due to a misconfiguration, or social engineering may be used to get a resource owner to
use an attacker-controlled resource server. Also see <xref target="comp_res_server"/>.</t>
</li>
</ul>
<t>(A3), (A4)
</ol>
<t><xref target="read_response" format="none">(A3)</xref>, <xref target="read_request" format="none">(A4)</xref>, and (A5) <xref target="acquire_token" format="none">(A5)</xref> typically occur together with either (A1) <xref target="web_attackers" format="none">(A1)</xref> or (A2). <xref target="network_attackers" format="none">(A2)</xref>.
Attackers can collaborate to reach a common goal.</t>
<t>Note that an attacker (A1) <xref target="web_attackers" format="none">(A1)</xref> or (A2) <xref target="network_attackers" format="none">(A2)</xref> can be a resource owner or
act as one. For example, such an attacker can use their own browser to replay
tokens or authorization codes obtained by any of the attacks described
above at the client or resource server.</t>
<t>This document focuses on threats resulting from attackers (A1) <xref target="web_attackers" format="none">(A1)</xref> to (A5).</t> <xref target="acquire_token" format="none">(A5)</xref>.</t>
</section>
<section anchor="attacks_and_mitigations"><name>Attacks and Mitigations</name>
<t>This section gives a detailed description of attacks on OAuth implementations,
along with potential countermeasures. Attacks and mitigations already covered in
<xref target="RFC6819"/> are not listed here, except where new recommendations are made.</t>
<t>This section further defines additional requirements beyond (beyond those defined in
<xref target="recommendations"/> target="recommendations"/>) for certain cases and protocol options.</t>
<section anchor="insufficient_uri_validation"><name>Insufficient Redirect URI Validation</name>
<t>Some authorization servers allow clients to register redirect URI
patterns instead of complete redirect URIs. The authorization servers
then match the redirect URI parameter value at the authorization
endpoint against the registered patterns at runtime. This approach
allows clients to encode transaction state into additional redirect
URI parameters or to register a single pattern for multiple
redirect URIs.</t>
<t>This approach turned out to be more complex to implement and more
error-prone to manage than exact redirect URI matching. Several
successful attacks exploiting flaws in the pattern-matching
implementation or concrete configurations have been observed in the
wild (see, e.g., <xref target="research.rub2"/>). Insufficient validation of the redirect URI effectively breaks
client identification or authentication (depending on grant and client
type) and allows the attacker to obtain an authorization code or
access token, either</t>
<ul spacing="compact">
<li>by directly sending the user agent to a URI under the attacker's
control, or</li>
<li>by exposing the OAuth credentials to an attacker by utilizing an
open redirector at the client in conjunction with the way user
agents handle URL fragments.</li>
</ul>
<t>These attacks are shown in detail in the following subsections.</t>
<section anchor="insufficient_uri_validation_acg"><name>Redirect URI Validation Attacks on Authorization Code Grant</name>
<t>For a client using the grant type <tt>code</tt>, an attack may work as
follows:</t>
<t>Assume the redirect URL pattern <tt>https://*.somesite.example/*</tt> is
registered for the client with the client ID <tt>s6BhdRkqt3</tt>. The
intention is to allow any subdomain of <tt>somesite.example</tt> to be a
valid redirect URI for the client, for example example,
<tt>https://app1.somesite.example/redirect</tt>. A However, a naive implementation on
the authorization server, however, server might interpret the wildcard <tt>*</tt> as
"any character" and not "any character valid for a domain name". The
authorization server, therefore, might permit
<tt>https://attacker.example/.somesite.example</tt> as a redirect URI,
although <tt>attacker.example</tt> is a different domain potentially
controlled by a malicious party.</t>
<t>The attack can then be conducted as follows:</t>
<t>To begin, the attacker needs to trick the user into opening a tampered
URL in their browser that launches a page under the attacker's
control, say say, <tt>https://www.evil.example</tt> (see Attacker A1 attacker <xref target="web_attackers" format="none">A1</xref> in <xref target="secmodel"/>).</t>
<t>This URL initiates the following authorization request with the client
ID of a legitimate client to the authorization endpoint (line breaks
for display only):</t>
<artwork><![CDATA[GET
<sourcecode><![CDATA[
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=9ad67f13
&redirect_uri=https%3A%2F%2Fattacker.example%2F.somesite.example
HTTP/1.1
Host: server.somesite.example
]]>
</artwork>
]]></sourcecode>
<t>The authorization server validates the redirect URI and compares it to
the registered redirect URL patterns for the client <tt>s6BhdRkqt3</tt>.
The authorization request is processed and presented to the user.</t>
<t>If the user does not see the redirect URI or does not recognize the
attack, the code is issued and immediately sent to the attacker's
domain. If an automatic approval of the authorization is enabled
(which is not recommended for public clients according to
<xref target="RFC6749"/>), the attack can be performed even without user
interaction.</t>
<t>If the attacker impersonates a public client, the attacker can
exchange the code for tokens at the respective token endpoint.</t>
<t>This attack will not work as easily for confidential clients, since
the code exchange requires authentication with the legitimate client's
secret. The However, the attacker can, however, can use the legitimate confidential
client to redeem the code by performing an authorization code
injection attack, attack; see <xref target="code_injection"/>.</t>
<t>It is important to note that redirect URI validation vulnerabilities can also exist if the authorization
server handles wildcards properly. For example, assume that the client
registers the redirect URL pattern <tt>https://*.somesite.example/*</tt> and
the authorization server interprets this as "allow redirect URIs
pointing to any host residing in the domain <tt>somesite.example</tt>". If an
attacker manages to establish a host or subdomain in
<tt>somesite.example</tt>, the attacker can impersonate the legitimate client. This For example, this
could be caused, for example, caused by a subdomain takeover attack <xref target="research.udel"/>, where an
outdated CNAME record (say, <tt>external-service.somesite.example</tt>)
points to an external DNS name that does no longer exist exists (say,
<tt>customer-abc.service.example</tt>) and can be taken over by an attacker
(e.g., by registering as <tt>customer-abc</tt> with the external service).</t>
</section>
<section anchor="redir_uri_open_redir"><name>Redirect URI Validation Attacks on Implicit Grant</name>
<t>The attack described above works for the implicit grant as well. If
the attacker is able to send the authorization response to an attacker-controlled URI, the attacker will directly get access to the fragment carrying the
access token.</t>
<t>Additionally, implicit grants (and also other grants when using <tt>response_mode=fragment</tt> as defined in <xref target="OAuth.Responses"/>) can be subject to a further kind of
attack. It The attack utilizes the fact that user agents re-attach reattach fragments to
the destination URL of a redirect if the location header does not
contain a fragment (see <xref target="RFC9110"/>, Section 17.11). target="RFC9110" sectionFormat="of" section="17.11"/>). The attack
described here combines this behavior with the client as an open
redirector (see <xref target="open_redirector_on_client"/>) in order to obtain access tokens. This allows
circumvention even of very narrow redirect URI patterns, but not of strict URL
matching.</t>
<t>Assume the registered URL pattern for client <tt>s6BhdRkqt3</tt> is
<tt>https://client.somesite.example/cb?*</tt>, i.e., any parameter is allowed
for redirects to <tt>https://client.somesite.example/cb</tt>. Unfortunately,
the client exposes an open redirector. This endpoint supports a
parameter <tt>redirect_to</tt> which takes a target URL and will send the
browser to this URL using an HTTP Location header redirect 303.</t>
<t>The attack can now be conducted as follows:</t>
<t>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
attacker's control, say say, <tt>https://www.evil.example</tt>.</t>
<t>Afterwards, the website initiates an authorization request that is
very similar to the one in the attack on the code flow. Different to
above, it utilizes the open redirector by encoding
<tt>redirect_to=https://attacker.example</tt> into the parameters of the
redirect URI URI, and it uses the response type "token" (line breaks for display only):</t>
<artwork><![CDATA[GET
<sourcecode><![CDATA[
GET /authorize?response_type=token&state=9ad67f13
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.somesite.example
%2Fcb%26redirect_to%253Dhttps%253A%252F
%252Fattacker.example%252F HTTP/1.1
Host: server.somesite.example
]]>
</artwork>
<t>Now,
]]></sourcecode>
<t>Then, since the redirect URI matches the registered pattern, the
authorization server permits the request and sends the resulting access
token in a 303 redirect (some response parameters omitted for
readability):</t>
<artwork><![CDATA[HTTP/1.1
<sourcecode><![CDATA[
HTTP/1.1 303 See Other
Location: https://client.somesite.example/cb?
redirect_to%3Dhttps%3A%2F%2Fattacker.example%2Fcb
#access_token=2YotnFZFEjr1zCsicMWpAA&...
]]>
</artwork>
]]></sourcecode>
<t>At client.somesite.example, the request arrives at the open redirector. The endpoint will
read the redirect parameter and will issue an HTTP 303 Location header
redirect to the URL <tt>https://attacker.example/</tt>.</t>
<artwork><![CDATA[HTTP/1.1
<sourcecode><![CDATA[
HTTP/1.1 303 See Other
Location: https://attacker.example/
]]>
</artwork>
]]></sourcecode>
<t>Since the redirector at client.somesite.example does not include a
fragment in the Location header, the user agent will re-attach reattach the
original fragment <tt>#access_token=2YotnFZFEjr1zCsicMWpAA&amp;...</tt> to
the URL and will navigate to the following URL:</t>
<artwork><![CDATA[https://attacker.example/#access_token=2YotnFZFEjr1z...
]]>
</artwork>
<artwork><![CDATA[
https://attacker.example/#access_token=2YotnFZFEjr1z...
]]></artwork>
<t>The attacker's page at <tt>attacker.example</tt> can now then access the
fragment and obtain the access token.</t>
</section>
<section anchor="iuv_countermeasures"><name>Countermeasures</name>
<t>The complexity of implementing and managing pattern matching correctly obviously
causes security issues. This document therefore advises simplifying the required
logic and configuration by using exact redirect URI matching. This means the
authorization server MUST <bcp14>MUST</bcp14> ensure that the two URIs are equal, equal; see <xref target="RFC3986"/>,
Section 6.2.1, target="RFC3986" sectionFormat="of" section="6.2.1"/>, Simple String Comparison, for details. The only exception is
native apps using a <tt>localhost</tt> URI: In this case, the authorization server MUST <bcp14>MUST</bcp14> allow variable
port numbers as described in <xref target="RFC8252"/>, Section 7.3.</t> target="RFC8252" sectionFormat="of" section="7.3"/>.</t>
<t>Additional recommendations:</t>
<ul spacing="compact">
<li>Web servers on which redirect URIs are hosted MUST NOT <bcp14>MUST NOT</bcp14> expose open
redirectors (see <xref target="open_redirection"/>).</li>
<li>Browsers reattach URL fragments to Location redirection URLs only
if the URL in the Location header does not already contain a fragment.
Therefore, servers MAY <bcp14>MAY</bcp14> prevent browsers from reattaching fragments
to redirection URLs by attaching an arbitrary fragment identifier,
for example <tt>#_</tt>, to URLs in Location headers.</li>
<li>Clients SHOULD <bcp14>SHOULD</bcp14> use the authorization code response type instead of
response types causing that cause access token issuance at the authorization
endpoint. This offers countermeasures against the reuse of leaked
credentials through the exchange process with the authorization
server and against token replay through sender-constraining of the access
tokens.</li>
</ul>
<t>If the origin and integrity of the authorization request containing
the redirect URI can be verified, for example example, when using
<xref target="RFC9101"/> or <xref target="RFC9126"/> with client
authentication, the authorization server MAY <bcp14>MAY</bcp14> trust the redirect URI
without further checks.</t>
</section>
</section>
<section anchor="credential_leakage_referrer"><name>Credential Leakage via Referer Headers</name>
<t>The contents of the authorization request URI or the authorization
response URI can unintentionally be disclosed to attackers through the
Referer HTTP header (see <xref target="RFC9110"/>, Section 10.1.3), target="RFC9110" sectionFormat="of" section="10.1.3"/>), by leaking either from either the authorization server's or the client's website, respectively. Most
importantly, authorization codes or <tt>state</tt> values can be disclosed in
this way. Although specified otherwise in <xref target="RFC9110"/>, Section 10.1.3, target="RFC9110" sectionFormat="of" section="10.1.3"/>,
the same may happen to access tokens conveyed in URI fragments due to
browser implementation issues, as illustrated by a (now fixed) issue in the Chromium project <xref target="bug.chromium"/>.</t>
<section anchor="leakage-from-the-oauth-client"><name>Leakage from the OAuth Client</name>
<t>Leakage from the OAuth client requires that the client, as a result of
a successful authorization request, renders a page that</t>
<ul spacing="compact">
<li>contains links to other pages under the attacker's control and a
user clicks on such a link, or</li>
<!--[rfced] Does 'iframes' refer to the iframe element in HTML?
If so, should a reference be added? We note RFC 6819 referred to HTML4.
Do you want to refer to the current version of HTML
(https://html.spec.whatwg.org/multipage/iframe-embed-object.html)
or otherwise?
Section 4.2.1:
* includes third-party content (advertisements in iframes, images,
etc.), for example, if the page contains user-generated content
(blog).
Section 4.16:
Clickjacking
attacks can be designed such that users can hardly notice the attack,
for example using almost invisible iframes overlaid on top of other
elements.
-->
<li>includes third-party content (advertisements in iframes, images,
etc.), for example, if the page contains user-generated content
(blog).</li>
</ul>
<t>As soon as the browser navigates to the attacker's page or loads the
third-party content, the attacker receives the authorization response
URL and can extract <tt>code</tt> or <tt>state</tt> (and potentially <tt>access_token</tt>).</t>
</section>
<section anchor="leakage-from-the-authorization-server"><name>Leakage from the Authorization Server</name>
<t>In a similar way, an attacker can learn <tt>state</tt> from the authorization
request if the authorization endpoint at the authorization server
contains links or third-party content as above.</t>
</section>
<section anchor="consequences"><name>Consequences</name>
<t>An attacker that learns a valid code or access token through a
Referer header can perform the attacks as described in Sections
<xref target="insufficient_uri_validation_acg"/>, target="insufficient_uri_validation_acg" format="counter"/>, <xref target="code_injection"/>, target="code_injection" format="counter"/> and
<xref target="access_token_injection"/>. target="access_token_injection" format="counter"/>. If the attacker learns <tt>state</tt>, the CSRF
protection achieved by using <tt>state</tt> is lost, resulting in CSRF
attacks as described in <xref target="RFC6819"/>, Section 4.4.1.8.</t> target="RFC6819" sectionFormat="of" section="4.4.1.8"/>.</t>
</section>
<section anchor="countermeasures"><name>Countermeasures</name>
<t>The page rendered as a result of the OAuth authorization response and
the authorization endpoint SHOULD NOT <bcp14>SHOULD NOT</bcp14> include third-party resources or
links to external sites.</t>
<t>The following measures further reduce the chances of a successful attack:</t>
<ul>
<li>Suppress the Referer header by applying an appropriate Referrer
Policy <xref target="W3C.webappsec-referrer-policy"/> to the document (either as
part of the "referrer" meta attribute or by setting a
Referrer-Policy header). For example, the header <tt>Referrer-Policy:
no-referrer</tt> in the response completely suppresses the Referer
header in all requests originating from the resulting document.</li>
<li>Use authorization code instead of response types causing access
token issuance from the authorization endpoint.</li>
<li>Bind the authorization code to a confidential client or PKCE
challenge. In this case, the attacker lacks the secret to request
the code exchange.</li>
<li><t>As described in <xref target="RFC6749"/>, Section 4.1.2, target="RFC6749" sectionFormat="of" section="4.1.2"/>, authorization codes
MUST
<bcp14>MUST</bcp14> be invalidated by the authorization server after their first use at the token
endpoint. For example, if an authorization server invalidated the code after the
legitimate client redeemed it, the attacker would fail to exchange
this code later.</t>
<t>This does not mitigate the attack if the attacker manages to
exchange the code for a token before the legitimate client does
so. Therefore, <xref target="RFC6749"/> further recommends that, when an
attempt is made to redeem a code twice, the authorization server SHOULD <bcp14>SHOULD</bcp14> revoke all
tokens issued previously based on that code.</t>
</li>
<li><t>The <tt>state</tt> value SHOULD <bcp14>SHOULD</bcp14> be invalidated by the client after its
first use at the redirection endpoint. If this is implemented, and
an attacker receives a token through the Referer header from the
client's website, the <tt>state</tt> was already used, invalidated by
the client and cannot be used again by the attacker. (This does
not help if the <tt>state</tt> leaks from the
authorization server's website, since then the <tt>state</tt>
has not been used at the redirection endpoint at the client yet.)</t>
</li>
<li><t>Use the form post response mode instead of a redirect for the
authorization response (see <xref target="OAuth.Post"/>).</t>
</li>
</ul>
</section>
</section>
<section anchor="browser_history"><name>Credential Leakage via Browser History</name>
<t>Authorization codes and access tokens can end up in the browser's
history of visited URLs, enabling the attacks described in the
following.</t>
<section anchor="authorization-code-in-browser-history"><name>Authorization Code in Browser History</name>
<t>When a browser navigates to
<tt>client.example/redirection_endpoint?code=abcd</tt> as a result of a
redirect from a provider's authorization endpoint, the URL including
the authorization code may end up in the browser's history. An
attacker with access to the device could obtain the code and try to
replay it.</t>
<t>Countermeasures:</t>
<ul spacing="compact">
<li>Authorization code replay prevention as described in <xref target="RFC6819"/>,
Section 4.4.1.1, target="RFC6819" sectionFormat="of" section="4.4.1.1"/>, and <xref target="code_injection"/>.</li>
<li>Use the form post response mode instead of redirect for the authorization
response (see <xref target="OAuth.Post"/>).</li>
</ul>
</section>
<section anchor="access-token-in-browser-history"><name>Access Token in Browser History</name>
<t>An access token may end up in the browser history if a client or a web
site website that already has a token deliberately navigates to a page like
<tt>provider.com/get_user_profile?access_token=abcdef</tt>. <xref target="RFC6750"/>
discourages this practice and advises transferring tokens via a header,
but in practice web sites websites often pass access tokens in query
parameters.</t>
<t>In the case of implicit grant, a URL like
<tt>client.example/redirection_endpoint#access_token=abcdef</tt> may also end
up in the browser history as a result of a redirect from a provider's
authorization endpoint.</t>
<t>Countermeasures:</t>
<ul spacing="compact">
<li>Clients MUST NOT <bcp14>MUST NOT</bcp14> pass access tokens in a URI query parameter in
the way described in Section 2.3 of <xref target="RFC6750"/>. target="RFC6750" sectionFormat="of" section="2.3"/>. The authorization
code grant or alternative OAuth response modes like the form post
response mode <xref target="OAuth.Post"/> can be used to
this end.</li>
</ul>
</section>
</section>
<section anchor="mix_up"><name>Mix-Up Attacks</name>
<t>Mix-up is an attack on attacks are in scenarios where an OAuth client interacts with
two or more authorization servers and at least one authorization
server is under the control of the attacker. This can be the case,
for example, if the attacker uses dynamic registration to register the
client at their own authorization server or if an authorization server
becomes compromised.</t>
<t>The goal of the attack is to obtain an authorization code or an access
token for an uncompromised authorization server. This is achieved by
tricking the client into sending those credentials to the compromised
authorization server (the attacker) instead of using them at the
respective endpoint of the uncompromised authorization/resource
server.</t>
<section anchor="attack-description"><name>Attack Description</name>
<t>The description here follows <xref target="arXiv.1601.01229"/>, with
variants of the attack outlined below.</t>
<t>Preconditions: For this variant of the attack to work, it is assumed that</t>
<ul spacing="compact">
<li>the implicit or authorization code grant is used with multiple authorization servers
of which one is considered "honest" (H-AS) and one is operated by
the attacker (A-AS), and</li>
<li>the client stores the authorization server chosen by the user in a session bound to
the user's browser and uses the same redirection endpoint URI for
each authorization server.</li>
</ul>
<t>In the following, it is further assumed that the client is registered with H-AS (URI:
<tt>https://honest.as.example</tt>, client ID: <tt>7ZGZldHQ</tt>) and with A-AS (URI:
<tt>https://attacker.example</tt>, client ID: <tt>666RVZJTA</tt>). URLs shown in the following
example are shortened for presentation to only include only parameters relevant to the
attack.</t>
<t>Attack on the authorization code grant:</t>
<ol>
<ol spacing="normal" type="1">
<li>The user selects to start the grant using A-AS (e.g., by clicking on a button on the
client's website).</li>
<li>The
<li anchor="step_2_mixup">The client stores in the user's session that the user selected
"A-AS" and redirects the user to A-AS's authorization endpoint
with a Location header containing the URL
<tt>https://attacker.example/authorize?response_type=code&client_id=666RVZJTA</tt>.</li>
<li>When the user's browser navigates to the attacker's authorization endpoint,
the attacker immediately redirects the browser to the authorization endpoint
of H-AS. In the authorization request, 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 redirection (<tt>303 (303 See Other</tt>) Other) with a Location header pointing to
<tt>https://honest.as.example/authorize?response_type=code&client_id=7ZGZldHQ</tt></li>
<li><t>The
<!--[rfced] Please clarify "avoids this". Does it mean that the first
attack variant prevents the vigilant user from detecting the attack?
If so, we suggest rephrasing it for clarity.
Original:
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
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
the browser) back to the client.
-->
<li anchor="step_4_mixup"><t>The user authorizes the client to access their resources at H-AS. (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 listed below avoids this.) H-AS
issues a code and sends it (via the browser) back to the client.</t>
</li>
<li><t>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.</t>
</li>
<li><t>The attacker therefore obtains code and can either exchange the
code for an access token (for public clients) or perform an
authorization code injection attack as described in
<xref target="code_injection"/>.</t>
</li>
</ol>
<t>Variants:</t>
<ul spacing="compact">
<li>Mix-Up With with Interception: This variant works only if the attacker can
intercept and manipulate the first request/response pair from a user's
browser to the client (in which the user selects a certain authorization server and is then
redirected by the client to that authorization server), as in Attacker A2 <xref target="network_attackers"
format="none">Attacker (A2)</xref> (see <xref target="secmodel"/>). This capability
can, for example, be the result of a attacker-in-the-middle attack on the user's
connection to the client. In the attack, the user starts the flow with H-AS.
The attacker intercepts this request and changes the user's selection to
A-AS. The rest of the attack proceeds as in Steps 2 <xref target="step_2_mixup" format="none">Step 2</xref> and following above.</li>
<li>Implicit Grant: In the implicit grant, the attacker receives an access
token instead of the code in Step 4. <xref target="step_4_mixup" format="none">Step 4</xref>. The attacker's authorization server receives the access token
when the client makes either a request to the A-AS userinfo endpoint, endpoint or since a request to the attacker's resource server (since the client believes it has completed the flow with A-AS, a request to the
attacker's resource server.</li> A-AS).</li>
<li>Per-AS Redirect URIs: If clients use different redirect URIs for
different authorization servers, clients do not store the selected authorization server in the user's session, and authorization servers
do not check the redirect URIs properly, attackers can mount an attack
called "Cross-Social Network Request Forgery". These attacks have been
observed in practice. Refer to <xref target="research.jcs_14"/> for details.</li>
<li>OpenID Connect: Some variants can be used to attack OpenID
Connect. In these attacks, the attacker misuses features of the OpenID
Connect Discovery <xref target="OpenID.Discovery"/> mechanism or replays access tokens or ID
Tokens to conduct a mix-up attack. The attacks are described in detail in
<xref target="arXiv.1704.08539"/>, Appendix A, and A of
<xref target="arXiv.1508.04324v2"/>, target="arXiv.1704.08539"/> and Section 6 of <xref target="arXiv.1508.04324v2"/> ("Malicious Endpoints Attacks").</li>
</ul>
</section>
<section anchor="mixupcountermeasures"><name>Countermeasures</name>
<t>When an OAuth client can only interact with one authorization server, a mix-up
defense is not required. In scenarios where an OAuth client interacts with two
or more authorization servers, however, clients MUST <bcp14>MUST</bcp14> prevent mix-up attacks. Two
different methods are discussed in the following.</t> below.</t>
<t>For both defenses, clients MUST <bcp14>MUST</bcp14> store, for each authorization request, the
issuer they sent the authorization request to and bind this information to the
user agent. The issuer serves, via the associated metadata, as an abstract
identifier for the combination of the authorization endpoint and token endpoint
that are to be used in the flow. If an issuer identifier is not available, for available (for
example, if neither OAuth Authorization Server Metadata <xref target="RFC8414"/> nor OpenID Connect Discovery <xref target="OpenID.Discovery"/> is
used,
used), a different unique identifier for this tuple or the tuple itself can be
used instead. For brevity of presentation, such a deployment-specific identifier
will be subsumed under the issuer (or issuer identifier) in the following.</t>
<t>It is important to note that just storing the authorization server URL is not sufficient to identify
mix-up attacks. An attacker might declare an uncompromised authorization server's authorization endpoint URL as
"their" authorization server URL, but declare a token endpoint under their own control.</t>
<section anchor="mix-up-defense-via-issuer-identification"><name>Mix-Up Defense via Issuer Identification</name>
<t>This defense requires that the authorization server sends its issuer identifier
in the authorization response to the client. When receiving the authorization
response, the client MUST <bcp14>MUST</bcp14> compare the received issuer identifier to the stored
issuer identifier. If there is a mismatch, the client MUST <bcp14>MUST</bcp14> abort the
interaction.</t>
<t>There are different ways this issuer identifier can be transported to the client:</t>
<ul spacing="compact">
<li>The issuer information can be transported, for
example, via a separate response parameter <tt>iss</tt>, defined in
<xref target="RFC9207"/>.</li>
<li>When OpenID Connect is used and an ID Token is returned in the authorization
response, the client can evaluate the <tt>iss</tt> claim in the ID Token.</li>
</ul>
<t>In both cases, the <tt>iss</tt> value MUST <bcp14>MUST</bcp14> be evaluated according to <xref target="RFC9207"/>.</t>
<t>While this defense may require deploying new OAuth features to transport the
issuer information, it is a robust and relatively simple defense against mix-up.</t>
</section>
<section anchor="mix-up-defense-via-distinct-redirect-uris"><name>Mix-Up Defense via Distinct Redirect URIs</name>
<t>For this defense, clients MUST <bcp14>MUST</bcp14> use a distinct redirect URI for each issuer
they interact with.</t>
<t>Clients MUST <bcp14>MUST</bcp14> check that the authorization response was received from the correct
issuer by comparing the distinct redirect URI for the issuer to the URI where
the authorization response was received on. If there is a mismatch, the client
MUST
<bcp14>MUST</bcp14> abort the flow.</t>
<t>While this defense builds upon existing OAuth functionality, it cannot be used
in scenarios where clients only register once for the use of many different
issuers (as in some open banking schemes) and due to the tight integration with
the client registration, it is harder to deploy automatically.</t>
<t>Furthermore, an attacker might be able to circumvent the protection offered by
this defense by registering a new client with the "honest" authorization server using the redirect
URI that the client assigned to the attacker's authorization server. The attacker could then run
the attack as described above, replacing the
client ID with the client ID of their newly created client.</t>
<t>This defense SHOULD <bcp14>SHOULD</bcp14> therefore only be used if other options are not available.</t>
</section>
</section>
</section>
<section anchor="code_injection"><name>Authorization Code Injection</name>
<t>An attacker who has gained access to an authorization code contained in an
authorization response (see Attacker A3 <xref target="read_response"
format="none">Attacker (A3)</xref> in <xref target="secmodel"/>) can try to redeem the
authorization code for an access token or otherwise make use of the
authorization code.</t>
<t>In the case that the authorization code was created for a public client, the
attacker can send the authorization code to the token endpoint of the
authorization server and thereby get an access token. This attack was described
in Section 4.4.1.1 of <xref target="RFC6819"/>.</t> target="RFC6819" sectionFormat="of" section="4.4.1.1."/>.</t>
<t>For confidential clients, or in some special situations, the attacker can
execute an authorization code injection attack, as described in the following.</t>
<t>In an authorization code injection attack, the attacker attempts to inject a
stolen authorization code into the attacker's own session 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 attacker at least limited access to
the victim's resources.</t>
<t>Besides circumventing the client authentication of confidential clients, other
use cases for this attack include:</t>
<ul spacing="compact">
<li>The attacker wants to access certain functions in this particular
client. As an example, the attacker wants to impersonate their
victim in a certain app or on a certain website.</li>
<li>The authorization or resource servers are limited to certain
networks that the attacker is unable to access directly.</li>
</ul>
<t>Except in these special cases, authorization code injection is usually not
interesting when the code is created for a public client, as sending the code
to the token endpoint is a simpler and more powerful attack, as described above.</t>
<section anchor="attack-description-1"><name>Attack Description</name>
<t>The authorization code injection attack works as follows:</t>
<ol spacing="compact"> spacing="compact" type="1">
<li>The attacker obtains an authorization code (see attacker A3 <xref target="read_response"
format="none">Attacker (A3)</xref> in <xref target="secmodel"/>). For the rest
of the attack, only the capabilities of a web attacker (A1) <xref target="web_attackers" format="none">(A1)</xref> are required.</li>
<li>From
<li anchor="step_2_code_injection">From the attacker's device, the attacker starts a regular OAuth authorization
process with the legitimate client.</li>
<li>In
<li anchor="step_3_code_injection">In the response of the authorization server to the legitimate client, the
attacker replaces the newly created authorization code with the stolen
authorization code. Since this response is passing through the attacker's
device, the attacker can use any tool that can intercept and manipulate the
authorization response to this end. The attacker does not need to control
the network.</li>
<li>The legitimate client sends the code to the authorization server's token
endpoint, along with the <tt>redirect_uri</tt> and the client's client ID and
client secret (or other means of client authentication).</li>
<li>The
<li anchor="checkin">The authorization server checks the client secret, whether the
code was issued to the particular client, and whether the actual
redirect URI matches the <tt>redirect_uri</tt> parameter (see
<xref target="RFC6749"/>).</li>
<li>All checks succeed and the authorization server issues access and
other tokens to the client. The attacker has now associated their
session with the legitimate client with the victim's resources
and/or identity.</li>
</ol>
</section>
<section anchor="discussion"><name>Discussion</name>
<t>Obviously, the check-in step (5.) (<xref target="checkin" format="none">Step 5</xref>) will fail if the code was 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 redeemed by the
legitimate user and was one-time use only.</t>
<t>An attempt to inject a code obtained via a manipulated redirect URI
should also be detected if the authorization server stored the
complete redirect URI used in the authorization request and compares
it with the <tt>redirect_uri</tt> parameter.</t>
<t><xref target="RFC6749"/>, Section 4.1.3, target="RFC6749" sectionFormat="of" section="4.1.3"/> requires the authorization server to "... </t>
<blockquote>
ensure that the
<tt>redirect_uri</tt> "redirect_uri" parameter is present if the <tt>redirect_uri</tt>
"redirect_uri" parameter was included in the initial authorization
request as described in Section 4.1.1, <xref target="RFC6749" section="4.1.1" sectionFormat="bare" />, and if included ensure that
their values are
identical.". In identical.
</blockquote>
<t>In the attack scenario described above, in <xref target="attack-description-1"/>, the legitimate
client would use the correct redirect URI it always uses for
authorization requests. But this URI would not match the tampered
redirect URI used by the attacker (otherwise, the redirect would not
land at the attacker's page). So So, the authorization server would detect
the attack and refuse to exchange the code.</t>
<t>This check could also detect attempts to inject an authorization
code that had been obtained from another instance of the same client
on another device if certain conditions are fulfilled:</t>
<ul spacing="compact">
<li>the redirect URI itself needs to contain contains a nonce or another kind
of one-time use, secret data and</li>
<li>the client has bound this data to this particular instance of the
client.</li>
</ul>
<t>But
<t>But, this approach conflicts with the idea of enforcing exact redirect
URI matching at the authorization endpoint. Moreover, it has been
observed that providers very often ignore the <tt>redirect_uri</tt> check
requirement at this stage, maybe because it doesn't seem to be
security-critical from reading the specification.</t>
<!-- START -->
<t>Other providers just pattern match the <tt>redirect_uri</tt> parameter
against the registered redirect URI pattern. This saves the
authorization server from storing the link between the actual redirect
URI and the respective authorization code for every transaction. But However,
this kind of check obviously does not fulfill the intent of the
specification, since the tampered redirect URI is not considered. So So,
any attempt to inject an authorization code obtained using the
<tt>client_id</tt> of a legitimate client or by utilizing the legitimate
client on another device will not be detected in the respective
deployments.</t>
<t>It is also assumed that the requirements defined in <xref target="RFC6749"/>,
Section 4.1.3, target="RFC6749" sectionFormat="of" section="4.1.3"/> increase client implementation complexity as clients
need to store or re-construct reconstruct the correct redirect URI for the call
to the token endpoint.</t>
<t>Asymmetric methods for client authentication do not stop this attack, as the
legitimate client authenticates at the token endpoint.</t>
<t>This document therefore recommends instead binding every authorization
code to a certain client instance on a certain device (or in a certain
user agent) in the context of a certain transaction using one of the
mechanisms described next.</t>
</section>
<section anchor="countermeasures-1"><name>Countermeasures</name>
<t>There are two good technical solutions to binding authorization codes to client
instances, outlined in the following.</t> as follows.</t>
<section anchor="pkce_as_injection_protection"><name>PKCE</name>
<t>The PKCE mechanism specified in <xref target="RFC7636"/> can be used as a countermeasure
(even though it was originally designed to secure native apps). When the
attacker attempts to inject an authorization code, the check of the
<tt>code_verifier</tt> fails: the client uses its correct verifier, but the code is
associated with a <tt>code_challenge</tt> that does not match this verifier.</t>
<t>PKCE does not only protect protects against the authorization code injection attack but
also protects authorization codes created for public clients: PKCE ensures that
an attacker cannot redeem a stolen authorization code at the token endpoint of
the authorization server without knowledge of the <tt>code_verifier</tt>.</t>
</section>
<section anchor="nonce_as_injection_protection"><name>Nonce</name>
<t>OpenID Connect's existing <tt>nonce</tt> parameter can protect against authorization
code injection attacks. The <tt>nonce</tt> value is one-time use and is created by the
client. The client is supposed to bind it to the user agent session and send it
with the initial request to the OpenID Provider (OP). The OP puts the received <tt>nonce</tt> value into the ID Token that is issued
as part of the code exchange at the token endpoint.
If an attacker injects an
authorization code in the authorization response, the nonce value in the client
session and the nonce <tt>nonce</tt> value in the ID token Token received from the token endpoint will not match match, and the attack is
detected. The assumption is that an attacker cannot get hold of the user agent
state on the victim's device (from which the attacker has stolen the respective authorization
code).</t>
<t>It is important to note that this countermeasure only works if the client
properly checks the <tt>nonce</tt> parameter in the ID Token obtained from the token endpoint and does not use any
issued token until this check has succeeded. More precisely, a client protecting
itself against code injection using the <tt>nonce</tt> parameter</t>
<ol spacing="compact">
<li>MUST spacing="compact" type="1">
<li><bcp14>MUST</bcp14> validate the <tt>nonce</tt> in the ID Token obtained from the token endpoint,
even if another ID Token was obtained from the authorization response
(e.g., <tt>response_type=code+id_token</tt>), and</li>
<li>MUST
<li><bcp14>MUST</bcp14> ensure that, unless and until that check succeeds, all tokens (ID
Tokens and the access token) are disregarded and not used for any other
purpose.</li>
</ol>
<t>It is important to note that <tt>nonce</tt> does not protect authorization codes of
public clients, as an attacker does not need to execute an authorization code
injection attack. Instead, an attacker can directly call the token endpoint with
the stolen authorization code.</t>
</section>
<section anchor="other-solutions"><name>Other Solutions</name>
<t>Other solutions, solutions like binding <tt>state</tt> to the code, sender-constraining the code
using cryptographic means, or per-instance client credentials are
conceivable, but lack support and bring new security requirements.</t>
<t>PKCE is the most obvious solution for OAuth clients clients, as it is available
today,
at the time of writing, while <tt>nonce</tt> is
appropriate for OpenID Connect clients.</t>
</section>
</section>
<section anchor="limitations"><name>Limitations</name>
<t>An attacker can circumvent the countermeasures described above if he they
can modify the <tt>nonce</tt> or <tt>code_challenge</tt> values that are used in the
victim's authorization request. The attacker can modify these values
to be the same ones as those chosen by the client in their own session
in Step 2 <xref target="step_2_code_injection" format="none">Step 2</xref> of the attack above. (This requires that the victim's
session with the client begins after the attacker started their session
with the client.) If the attacker is then able to capture the
authorization code from the victim, the attacker will be able to
inject the stolen code in Step 3 <xref target="step_3_code_injection" format="none">Step 3</xref> even if PKCE or <tt>nonce</tt> are used.</t>
<t>This attack is complex and requires a close interaction between the
attacker and the victim's session. Nonetheless, measures to prevent
attackers from reading the contents of the authorization response
still need to be taken, as described in Sections
<xref target="insufficient_uri_validation"/>, target="insufficient_uri_validation" format="counter"/>, <xref target="credential_leakage_referrer"/>, target="credential_leakage_referrer" format="counter"/>,
<xref target="browser_history"/>, target="browser_history" format="counter"/>, <xref target="mix_up"/>, target="mix_up" format="counter"/>, and <xref target="open_redirection"/>.</t> target="open_redirection" format="counter"/>.</t>
</section>
</section>
<section anchor="access_token_injection"><name>Access Token Injection</name>
<t>In an access token injection attack, the attacker attempts to inject a
stolen access token into a legitimate client (that is not under the
attacker's control). This will typically happen if the attacker wants
to utilize a leaked access token to impersonate a user in a certain
client.</t>
<t>To conduct the attack, the attacker starts an OAuth flow with the
client using the implicit grant and modifies the authorization
response by replacing the access token issued by the authorization
server or directly making up an authorization server response including
the leaked access token. Since the response includes the <tt>state</tt> value
generated by the client for this particular transaction, the client
does not treat the response as a CSRF attack and uses the access token
injected by the attacker.</t>
<section anchor="countermeasures-2"><name>Countermeasures</name>
<t>There is no way to detect such an injection attack in pure-OAuth
flows since the token is issued without any binding to the
transaction or the particular user agent.</t>
<t>In OpenID Connect, the attack can be mitigated, as the authorization response
additionally contains an ID Token containing the <tt>at_hash</tt> claim. The attacker
therefore needs to replace both the access token as well as the ID Token in the
response. The attacker cannot forge the ID Token, as it is signed or encrypted
with authentication. The attacker also cannot inject a leaked ID Token matching
the stolen access token, as the <tt>nonce</tt> claim in the leaked ID Token will
contain (with a very high probability) contain a different value than the one expected
in the authorization response.</t>
<t>Note that further protection, like sender-constrained access tokens, is still
required to prevent attackers from using the access token at the resource
endpoint directly.</t>
<t>The recommendations in <xref target="implicit_grant_recommendation"/> follow from this.</t>
</section>
</section>
<section anchor="csrf"><name>Cross-Site Request Forgery</name>
<t>An attacker might attempt to inject a request to the redirect URI 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
variant of an attack known as Cross-Site Request Forgery (CSRF).</t>
<section anchor="csrf_countermeasures"><name>Countermeasures</name>
<t>The long-established countermeasure is that clients pass a random value, also
known as a CSRF Token, in the <tt>state</tt> parameter that links the request to
the redirect URI to the user agent session as described. This
countermeasure is described in detail in <xref target="RFC6819"/>, Section 5.3.5. target="RFC6819" sectionFormat="of" section="5.3.5"/>. The
same protection is provided by PKCE or the OpenID Connect <tt>nonce</tt> value.</t>
<t>When using PKCE instead of <tt>state</tt> or <tt>nonce</tt> for CSRF protection, it is
important to note that:</t>
<ul>
<li><t>Clients MUST <bcp14>MUST</bcp14> ensure that the authorization server supports PKCE before using PKCE for
CSRF protection. If an authorization server does not support PKCE,
<tt>state</tt> or <tt>nonce</tt> MUST <bcp14>MUST</bcp14> be used for CSRF protection.</t>
</li>
<!--[rfced] May this sentence be updated for clarity, as follows
or otherwise?
Original:
This can be achieved by binding the
contents of state to the browser session and/or signed/encrypted
state values.
Perhaps:
This can be achieved by binding the contents of state to
the browser session and/or by signing/encrypting state values.
-->
<li><t>If <tt>state</tt> is used for carrying application state, and the integrity of
its contents is a concern, clients MUST <bcp14>MUST</bcp14> protect <tt>state</tt> against
tampering and swapping. This can be achieved by binding the
contents of state to the browser session and/or signed/encrypted
state values. One example of this is discussed in the now-expired draft expired Internet-Draft <xref target="I-D.bradley-oauth-jwt-encoded-state"/>.</t>
</li>
</ul>
<t>The authorization server therefore MUST <bcp14>MUST</bcp14> provide a way to detect their support for PKCE. Using Authorization Server Metadata according to <xref target="RFC8414"/> is RECOMMENDED, <bcp14>RECOMMENDED</bcp14>, but authorization servers MAY <bcp14>MAY</bcp14> instead provide a
deployment-specific way to ensure or determine PKCE support.</t>
<t>PKCE provides robust protection against CSRF attacks even in the presence of an attacker that
can read the authorization response (see Attacker A3 <xref target="read_response"
format="none">Attacker (A3)</xref> in <xref target="secmodel"/>). When
<tt>state</tt> is used or an ID Token is returned in the authorization response (e.g.,
<tt>response_type=code+id_token</tt>), the attacker either learns the <tt>state</tt> value and
can replay it into the forged authorization response, or can extract the <tt>nonce</tt>
from the ID Token and use it in a new request to the authorization server to
mint an ID Token with the same <tt>nonce</tt>. The new ID Token can then be used for
the CSRF attack.</t>
</section>
</section>
<section anchor="pkce-downgrade-attack"><name>PKCE Downgrade Attack</name>
<t>An authorization server that supports PKCE but does not make its use mandatory for
all flows can be susceptible to a PKCE downgrade attack.</t>
<t>The first prerequisite for this attack is that there is an attacker-controllable
flag in the authorization request that enables or disables PKCE for the
particular flow. The presence or absence of the <tt>code_challenge</tt> parameter lends
itself for this purpose, i.e., the authorization server enables and enforces PKCE if this
parameter is present in the authorization request, but it does not enforce PKCE if
the parameter is missing.</t>
<t>The second prerequisite for this attack is that the client is not using <tt>state</tt>
at all (e.g., because the client relies on PKCE for CSRF prevention) or that the
client is not checking <tt>state</tt> correctly.</t>
<t>Roughly speaking, this attack is a variant of a CSRF attack. The attacker
achieves the same goal as in the attack described in <xref target="csrf"/>: The attacker injects an
authorization code (and with that, an access token) that is bound to the attacker's
resources into a session between their victim and the client.</t>
<section anchor="attack-description-2"><name>Attack Description</name>
<ol spacing="compact"> spacing="compact" type="1">
<li>The user has started an OAuth session using some client at an authorization server. In the
authorization request, the client has set the parameter
<tt>code_challenge=hash(abc)</tt> as the PKCE code challenge (with the hash function and parameter encoding as defined in <xref target="RFC7636"/>). The client is now
waiting to receive the authorization response from the user's browser.</li>
<li>To conduct the attack, the attacker uses their own device to start an
authorization flow with the targeted client. The client now uses another
PKCE code challenge, say say, <tt>code_challenge=hash(xyz)</tt>, in the authorization
request. The attacker intercepts the request and removes the entire
<tt>code_challenge</tt> parameter from the request. Since this step is performed on
the attacker's device, the attacker has full access to the request contents,
for example example, using browser debug tools.</li>
<li>If the authorization server allows for flows without PKCE, it will create a
code that is not bound to any PKCE code challenge.</li>
<li>The attacker now redirects the user's browser to an authorization response
URL that contains the code for the attacker's session with the authorization server.</li>
<li>The user's browser sends the authorization code to the client, which will
now try to redeem the code for an access token at the authorization server. The client will
send <tt>code_verifier=abc</tt> as the PKCE code verifier in the token request.</li>
<li>Since the authorization server sees that this code is not bound to any PKCE
code challenge, it will not check the presence or contents of the
<tt>code_verifier</tt> parameter. It will issue an access token that (which belongs to the
attacker's resource resource) to the client under the user's control.</li>
</ol>
</section>
<section anchor="pkce_downgrade_countermeasures"><name>Countermeasures</name>
<t>Using <tt>state</tt> properly would prevent this attack. However, practice has shown
that many OAuth clients do not use or check <tt>state</tt> properly.</t>
<t>Therefore, authorization servers MUST <bcp14>MUST</bcp14> mitigate this attack.</t>
<t>Note that from the view of the authorization server, in the attack described above, a
<tt>code_verifier</tt> parameter is received at the token endpoint although no
<tt>code_challenge</tt> parameter was present in the authorization request for the
OAuth flow in which the authorization code was issued.</t>
<t>This fact can be used to mitigate this attack. <xref target="RFC7636"/> already mandates that</t>
<ul spacing="compact">
<li>an authorization server that supports PKCE MUST <bcp14>MUST</bcp14> check whether a code challenge is contained in
the authorization request and bind this information to the code that is
issued; and</li>
<li>when a code arrives at the token endpoint, and there was a <tt>code_challenge</tt>
in the authorization request for which this code was issued, there must be a
valid <tt>code_verifier</tt> in the token request.</li>
</ul>
<t>Beyond this, to prevent PKCE downgrade attacks, the authorization server MUST <bcp14>MUST</bcp14> ensure that
if there was no <tt>code_challenge</tt> in the authorization request, a request to
the token endpoint containing a <tt>code_verifier</tt> is rejected.</t>
<t>Authorization servers that mandate the use of PKCE in (in general or for particular clients clients)
implicitly implement this security measure.</t>
</section>
</section>
<section anchor="access_token_leakage"><name>Access Token Leakage at the Resource Server</name>
<t>Access tokens can leak from a resource server under certain
circumstances.</t>
<section anchor="counterfeit_res_server"><name>Access Token Phishing by Counterfeit Resource Server</name>
<t>An attacker may set up their own resource server and trick a client into
sending access tokens to it that are valid for other resource servers
(see Attackers A1 <xref target="web_attackers" format="none">(A1)</xref> and A5 <xref target="acquire_token" format="none">(A5)</xref> in <xref target="secmodel"/>). If the client sends a valid access token to
this counterfeit resource server, the attacker in turn may use that
token to access other services on behalf of the resource owner.</t>
<t>This attack assumes the client is not bound to one specific resource
server (and its URL) at development time, but client instances are
provided with the resource server URL at runtime.
<!--[rfced] Regarding this sentence:
a) Please clarify; what does "this user or company" refer to
in this sentence? Is it the same as the client using the service,
mentioned at the start of the sentence?
b) Does "health" refer to "healthcare"?
Original:
This kind of late
binding is typical in situations where the client uses a service
implementing a standardized API (e.g., for e-mail, calendar, health,
or banking) and where the client is configured by a user or
administrator for a service that this user or company uses.
Perhaps:
This kind of late
binding is typical in situations where the client uses a service
implementing a standardized API (e.g., for email, calendaring,
healthcare, or banking) and where the client is configured by a user or
administrator for a service that the client uses.
-->
This kind of late
binding is typical in situations where the client uses a service
implementing a standardized API (e.g., for email, calendar, health,
or banking) and where the client is configured by a user or
administrator for a service that this user or company uses.</t>
</section>
<section anchor="comp_res_server"><name>Compromised Resource Server</name>
<t>An attacker may compromise a resource server to gain access to the
resources of the respective deployment. Such a compromise may range
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
circumvented and all resources can be
accessed. The attacker would also be able to obtain other access
tokens held on the compromised system that would potentially be valid
to access other resource servers.</t>
<t>Preventing server breaches by hardening and monitoring server systems
is considered a standard operational procedure and, therefore, out of
the scope of this document.
<!--[rfced] Section 4.9.2: Does "This section" refer to Section 4.9
(Access Token Leakage at the Resource Server) or otherwise?
Original:
This section focuses on the impact of
OAuth-related breaches and the replaying of captured access tokens.
-->
This section focuses on the impact of
OAuth-related breaches and the replaying of captured access tokens.</t>
</section>
<section anchor="countermeasures-3"><name>Countermeasures</name>
<t>The following measures should be taken into account by implementers in
order to cope with access token replay by malicious actors:</t>
<ul spacing="compact">
<li>Sender-constrained access tokens, as described in <xref target="pop_tokens"/>,
SHOULD
<bcp14>SHOULD</bcp14> be used to prevent the attacker from replaying the access
tokens on other resource servers. If an attacker has only partial
access to the compromised system, like a read-only access to web
server logs, sender-constrained access tokens may also prevent
replay on the compromised system.</li>
<li>Audience restriction as described in <xref target="aud_restriction"/> SHOULD <bcp14>SHOULD</bcp14> be
used to prevent replay of captured access tokens on other resource
servers.</li>
<li>The resource server MUST <bcp14>MUST</bcp14> treat access tokens like other sensitive secrets
and not store or transfer them in plain text.</li> plaintext.</li>
</ul>
<t>The first and second recommendations also apply to other scenarios
where access tokens leak (see Attacker A5 <xref target="acquire_token" format="none">Attacker (A5)</xref> in <xref target="secmodel"/>).</t>
</section>
</section>
<section anchor="misuse-of-stolen-access-tokens"><name>Misuse of Stolen Access Tokens</name>
<t>Access tokens can be stolen by an attacker in various ways, for example,
via the attacks described in Sections <xref target="insufficient_uri_validation"/>, target="insufficient_uri_validation" format="counter"/>,
<xref target="credential_leakage_referrer"/>, target="credential_leakage_referrer" format="counter"/>, <xref target="browser_history"/>, target="browser_history" format="counter"/>, <xref target="mix_up"/> target="mix_up" format="counter"/>, and
<xref target="access_token_leakage"/>. target="access_token_leakage" format="counter"/>. Some of these attacks can be mitigated by
specific security measures, as described in the respective sections.
However, in some cases, these measures are not sufficient or are not
implemented correctly. Authorization servers therefore SHOULD <bcp14>SHOULD</bcp14> ensure that
access tokens are sender-constrained and audience-restricted as described
in the following. Architecture and performance reasons may
prevent the use of these measures in some deployments.</t>
<section anchor="pop_tokens"><name>Sender-Constrained Access Tokens</name>
<t>As the name suggests, sender-constrained access tokens scope the
applicability of an access token to a certain sender. This sender is
obliged to demonstrate knowledge of a certain secret as a prerequisite
for the acceptance of that token at a resource server.</t>
<t>A typical flow looks like this:</t>
<ol spacing="compact">
<li>The authorization server associates data with the access token
that binds this particular token to a certain client. The binding
can utilize the client's identity, but in most cases, the authorization server utilizes
key material (or data derived from the key material) known to the
client.</li>
<li>This key material must be distributed somehow. Either the key
material already exists before the authorization server creates the binding or the
authorization server creates ephemeral keys. The way pre-existing preexisting key material is
distributed varies among the different approaches. For example,
X.509 Certificates certificates can be used, in which case the distribution
happens explicitly during the enrollment process. Or Or, the key
material is created and distributed at the TLS layer, in which
case it might automatically happen during the setup of a TLS
connection.</li>
<li>The resource server must implement the actual proof of possession proof-of-possession check. This
is typically done on the application level, often tied to specific
material provided by the transport layer (e.g., TLS). The resource server must also
ensure that a replay of the proof of possession is not possible.</li>
</ol>
<t>Two methods for sender-constrained access tokens using proof-of-possession proof of possession have
been defined by the OAuth working group and are in use in practice:</t>
<ul spacing="compact">
<li>OAuth
<li>"OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound
Access Tokens (<xref target="RFC8705"/>): Tokens" <xref target="RFC8705"/>: The approach specified in this this)
document allows the use of mutual TLS (mTLS) for both client
authentication and sender-constrained access tokens. For the
purpose of sender-constrained access tokens, the client is
identified towards the resource server by the fingerprint of its
public key. During the processing of an access token request, the
authorization server obtains the client's public key from the TLS
stack and associates its fingerprint with the respective access
tokens. The resource server in the same way obtains the public key
from the TLS stack and compares its fingerprint with the
fingerprint associated with the access token.</li>
<li>OAuth
<li>"OAuth 2.0 Demonstrating Proof of Possession (DPoP) (<xref target="RFC9449"/>): (DPoP)" <xref target="RFC9449"/>:
<!--[rfced] Please clarify this sentence; it seems to be missing words.
Original:
DPoP outlines an application-level sender-constraining for access
and refresh tokens.
Perhaps:
DPoP outlines an application-level mechanism for sender-constraining
access and refresh tokens.
-->
DPoP outlines an
application-level sender-constraining for access and refresh
tokens. It uses
proof-of-possession based on a public/private key pair and
application-level signing. DPoP can be used with public clients
and, in the case of confidential clients, can be combined with any
client authentication method.</li>
</ul>
<t>Note that the security of sender-constrained tokens is undermined when
an attacker gets access to the token and the key material. This is, in
particular, the case for corrupted client software and cross-site
scripting attacks (when the client is running in the browser). If the
key material is protected in a hardware or software security module or
only indirectly accessible (like in a TLS stack), sender-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 not available
to the attacker. This applies to access tokens as well as to refresh
tokens (see <xref target="refresh_token_protection"/>).</t>
</section>
<section anchor="aud_restriction"><name>Audience-Restricted Access Tokens</name>
<t>Audience restriction essentially restricts access tokens to a
particular resource server. The authorization server associates the
access token with the particular resource server server, and the resource
server is then supposed to verify the intended audience. If the access token fails
the intended audience validation, the resource server refuses to
serve the respective request.</t>
<t>In general, audience restriction limits the impact of token leakage.
In the case of a counterfeit resource server, it may (as described
below) also prevent abuse of the phished access token at the
legitimate resource server.</t>
<t>The audience can be expressed using logical names or
physical addresses (like URLs). To prevent phishing, it is
necessary to use the actual URL the client will send requests to. In
the phishing case, this URL will point to the counterfeit resource
server. If the attacker tries to use the access token at the
legitimate resource server (which has a different URL), the resource
server will detect the mismatch (wrong audience) and refuse to serve
the request.</t>
<t>In deployments where the authorization server knows the URLs of all
resource servers, the authorization server may just refuse to issue
access tokens for unknown resource server URLs.</t>
<t>For this to work, the client needs to tell the authorization server the intended
resource server. The mechanism in <xref target="RFC8707"/> can be used for this or the
information can be encoded in the scope value (Section 3.3 of <xref target="RFC6749"/>).</t> (<xref target="RFC6749" sectionFormat="of" section="3.3"/>).</t>
<t>Instead of the URL, it is also possible to utilize the fingerprint of
the resource server's X.509 certificate as the audience value. This
variant would also allow detection of an attempt to spoof the legitimate
resource server's URL by using a valid TLS certificate obtained from a
different CA. It might also be considered a privacy benefit to hide
the resource server URL from the authorization server.</t>
<t>Audience restriction may seem easier to use since it does not require
any cryptography on the client side. Still, since every access token is
bound to a specific resource server, the client also needs to obtain a
single resource server-specific access token when accessing several resource
servers. (Resource indicators, as specified in
<xref target="RFC8707"/>, can help to achieve this.)
<xref target="I-D.ietf-oauth-token-binding"/> had the same property since different
token-binding IDs must be associated with the access token. Using
Mutual TLS for OAuth 2.0 <xref target="RFC8705"/>, on the other hand, allows a client to use the
access token at multiple resource servers.</t>
<t>It should be noted that audience restrictions, or restrictions -- or, generally speaking speaking, an
indication by the client to the authorization server where it wants to
use the access token, token -- have additional benefits beyond the scope of
token leakage prevention. It allows They allow the authorization server to create
a different access token whose format and content are specifically minted
for the respective server. This has huge functional and privacy
advantages in deployments using structured access tokens.</t>
</section>
<section anchor="discussion-preventing-leakage-via-metadata"><name>Discussion: Preventing Leakage via Metadata</name>
<t>An authorization server could provide the client with additional
information about the locations where it is safe to use its access
tokens. This approach, and why it is not recommended, is discussed in
the following.</t>
<t>In the simplest form, this would require the authorization server to publish a list of
its known resource servers, illustrated in the following example using
a non-standard Authorization Server Metadata parameter <tt>resource_servers</tt>:</t>
<artwork><![CDATA[HTTP/1.1
<sourcecode><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json
{
"issuer":"https://server.somesite.example",
"authorization_endpoint":
"https://server.somesite.example/authorize",
"resource_servers":[
"email.somesite.example",
"storage.somesite.example",
"video.somesite.example"
]
...
}
]]>
</artwork>
]]></sourcecode>
<t>The authorization server could also return the URL(s) an access token is good for in the
token response, illustrated by the example and non-standard return
parameter <tt>access_token_resource_server</tt>:</t>
<artwork><![CDATA[HTTP/1.1
<sourcecode><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"access_token_resource_server":
"https://hostedresource.somesite.example/path1",
...
}
]]>
</artwork>
]]></sourcecode>
<t>This mitigation strategy would rely on the client to enforce the
security policy and to only send access tokens to legitimate
destinations. Results of OAuth-related security research (see (see, for
example
example, <xref target="research.ubc"/> and <xref target="research.cmu"/>) indicate a
large portion of client implementations do not or fail to properly
implement security controls, like <tt>state</tt> checks. So So, relying on
clients to prevent access token phishing is likely to fail as well.
<!--[rfced] Does "those entities" refer to the authorization and resource
servers? If so, we suggest changing to "those servers".
Original:
Moreover, given the ratio of clients to authorization and resource servers,
it is considered the more viable approach to move as much as possible
security-related logic to those entities.
Suggested:
Moreover, given the ratio of clients to authorization and resource servers,
it is considered the more viable approach to move as much as possible
security-related logic to those servers.
-->
Moreover, given the ratio of clients to authorization and resource
servers, it is considered the more viable approach to move as much as
possible security-related logic to those entities. Clearly, the client
has to contribute to the overall security. However, there are alternative
countermeasures, as described before, that provide a
better balance between the involved parties.</t>
<!--[rfced] Where are the alternative countermeasures described?
We suggest changing "as described before" to "as described
in Section X".
Original:
However, there are alternative countermeasures, as described before,
that provide a better balance between the involved parties.
-->
</section>
</section>
<section anchor="open_redirection"><name>Open Redirection</name>
<t>The following attacks can occur when an authorization server or client has an open redirector. Such endpoints are sometimes 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 they were intending to visit before
being interrupted, e.g., by a login prompt.</t>
<section anchor="open_redirector_on_client"><name>Client as Open Redirector</name>
<t>Clients MUST NOT <bcp14>MUST NOT</bcp14> expose open redirectors. Attackers may use open
redirectors to produce URLs pointing to the client and utilize them to
exfiltrate authorization codes and access tokens, as described in
<xref target="redir_uri_open_redir"/>. Another abuse case is to produce URLs that
appear to point to the client. This might trick users into trusting the URL
and following it in their browser. This can be abused for phishing.</t>
<t>In order to prevent open redirection, clients should only redirect if
the target URLs are allowed or if the origin and integrity of a
request can be authenticated. Countermeasures against open redirection
are described by OWASP <xref target="owasp.redir"/>.</t>
</section>
<section anchor="authorization-server-as-open-redirector"><name>Authorization Server as Open Redirector</name>
<t>Just as with clients, attackers could try to utilize a user's trust in
the authorization server (and its URL in particular) for performing
phishing attacks. OAuth authorization servers regularly redirect users
to other websites (the clients), but they must do so safely.</t>
<t><xref target="RFC6749"/>, Section 4.1.2.1, target="RFC6749" sectionFormat="of" section="4.1.2.1"/> already prevents open redirects by
stating that the authorization server MUST NOT <bcp14>MUST NOT</bcp14> automatically redirect the user agent in case
of an invalid combination of <tt>client_id</tt> and <tt>redirect_uri</tt>.</t>
<t>However, an attacker could also utilize a correctly registered
redirect URI to perform phishing attacks. The attacker could, for
example, register a client via dynamic client registration <xref target="RFC7591"/>
and execute one of the following attacks:</t>
<ol spacing="compact">
<li>Intentionally send an erroneous authorization request, e.g., by using an
invalid scope value, thus instructing the authorization server to redirect
the user-agent user agent to its phishing site.</li>
<li>Intentionally send a valid authorization request with <tt>client_id</tt> and
<tt>redirect_uri</tt> controlled by the attacker. After the user authenticates, the
authorization server prompts the user to provide consent to the request. If
the user notices an issue with the request and declines the request, the
authorization server still redirects the user agent to the phishing site. In
this case, the user agent will be redirected to the phishing site regardless
of the action taken by the user.</li>
<li>Intentionally send a valid silent authentication request (<tt>prompt=none</tt>)
with <tt>client_id</tt> and <tt>redirect_uri</tt> controlled by the attacker. In this
case, the authorization server will automatically redirect the user agent to
the phishing site.</li>
</ol>
<t>The authorization server MUST <bcp14>MUST</bcp14> take precautions to prevent these threats. The authorization server MUST <bcp14>MUST</bcp14> always
authenticate the user first and, with the exception of the silent authentication
use case, prompt the user for credentials when needed, before redirecting the
user. Based on its risk assessment, the authorization server needs to decide whether or not it can trust
the redirect URI or not. URI. It could take into account URI analytics done
internally or through some external service to evaluate the credibility and
trustworthiness of content behind the URI, and the source of the redirect URI and
other client data.</t>
<t>The authorization server SHOULD <bcp14>SHOULD</bcp14> only automatically redirect the user agent if it trusts the
redirect URI. If the URI is not trusted, the authorization server MAY <bcp14>MAY</bcp14> inform the user and rely on
the user to make the correct decision.</t>
</section>
</section>
<section anchor="redirect_307"><name>307 Redirect</name>
<t>At the authorization endpoint, a typical protocol flow is that the authorization server
prompts the user to enter their credentials in a form that is then
submitted (using the HTTP POST method) back to the authorization
server. The authorization server checks the credentials and, if successful, redirects
the user agent to the client's redirection endpoint.</t>
<t>In <xref target="RFC6749"/>, the HTTP status code 302 (Found) is used for this purpose, but
"any other method available via the user-agent to accomplish this
redirection is allowed". When the status code 307 is used for
redirection instead, the user agent will send the user's credentials via
HTTP POST to the client.</t>
<t>This discloses the sensitive credentials to the client. If the client
is malicious, it can use the credentials to impersonate the user
at the authorization server.</t>
<t>The behavior might be unexpected for developers but is defined in
<xref target="RFC9110"/>, Section 15.4.8. target="RFC9110" sectionFormat="of" section="15.4.8"/>. This status code (307) does not require the user
agent to rewrite the POST request to a GET request and thereby drop
the form data in the POST request body.</t>
<t>In the HTTP standard <xref target="RFC9110"/>, only the status code 303
unambiguously enforces rewriting the HTTP POST request to an HTTP GET
request.
<!--[rfced] For clarity, may this sentence be rephrased?
Specifically, they "can opt not to X and therefore to reveal Y"
is perhaps more clear as they "can opt not to X, thereby causing
Y to be revealed"?
Original:
For all other status codes, including the popular 302, user
agents can opt not to rewrite POST to GET requests and therefore to
reveal the user's credentials to the client.
Perhaps:
For all other status codes, including the popular 302, user
agents can opt not to rewrite POST to GET requests, thereby
causing the user's credentials to be revealed to the client.
-->
For all other status codes, including the popular 302, user
agents can opt not to rewrite POST to GET requests and therefore to
reveal the user's credentials to the client. (In practice, however, most
user agents will only show this behaviour behavior for 307 redirects.)</t>
<t>Authorization servers that redirect a request that potentially contains the user's credentials
therefore MUST NOT <bcp14>MUST NOT</bcp14> use the HTTP 307 status code for redirection. If an
HTTP redirection (and not, for example, JavaScript) is used for such a
request, the authorization server SHOULD <bcp14>SHOULD</bcp14> use HTTP status code 303 (See Other).</t>
</section>
<section anchor="tls_terminating"><name>TLS Terminating Reverse Proxies</name>
<t>A common deployment architecture for HTTP applications is to hide the
application server behind a reverse proxy that terminates the TLS
connection and dispatches the incoming requests to the respective
application server nodes.</t>
<t>This section highlights some attack angles of this deployment
architecture with relevance to OAuth and gives recommendations for
security controls.</t>
<t>In some situations, the reverse proxy needs to pass security-related
data to the upstream application servers for further processing.
Examples include the IP address of the request originator, token-binding
IDs, and authenticated TLS client certificates. This data is usually
passed in HTTP headers added to the upstream request. While the headers
are often custom, application-specific headers, standardized header
fields for client certificates and client certificate chains are defined
in <xref target="RFC9440"/>.</t>
<t>If the reverse proxy passes through any header sent from the
outside, an attacker could try to directly send the faked header
values through the proxy to the application server in order to
circumvent security controls that way. For example, it is standard
practice of reverse proxies to accept <tt>X-Forwarded-For</tt> headers and just
add the origin of the inbound request (making it a list). Depending on
the logic performed in the application server, the attacker could
simply add an allowed IP address to the header and render the protection useless.</t>
<t>A reverse proxy MUST <bcp14>MUST</bcp14> therefore sanitize any inbound requests to ensure
the authenticity and integrity of all header values relevant for the
security of the application servers.</t>
<t>If an attacker were able to get access to the internal network between
the proxy and application server, the attacker could also try to
circumvent security controls in place. It is, therefore, Therefore, it is essential to
ensure the authenticity of the communicating entities. Furthermore,
the communication link between the reverse proxy and application server
MUST
<bcp14>MUST</bcp14> be protected against eavesdropping, injection, and replay of
messages.</t>
</section>
<section anchor="refresh_token_protection"><name>Refresh Token Protection</name>
<!--[rfced] This sentence does not parse; please rephrase,
in particular "the full scope of grant a resource owner delegated".
Original:
Refresh tokens are an attractive target for attackers since they
represent the full scope of grant a resource owner delegated to a
certain client and they are not further constrained to a specific
resource.
Perhaps:
Refresh tokens are an attractive target for attackers because they
represent the full scope of grants that a resource owner delegated to
a certain client, and they are not further constrained to a specific
resource.
-->
<t>Refresh tokens are a convenient and user-friendly way to obtain new access
tokens. They also add
to the security of OAuth, since they allow the authorization server to issue
access tokens with a short lifetime and reduced scope, thus reducing the
potential impact of access token leakage.</t>
<section anchor="discussion-1"><name>Discussion</name>
<t>Refresh tokens are an attractive target for attackers since they
represent the full scope of grant a resource owner delegated to a certain
client and they are not further constrained to a specific resource. If an attacker is able to exfiltrate and successfully replay a
refresh token, the attacker will be able to mint access tokens and use
them to access resource servers on behalf of the resource owner.</t>
<t><xref target="RFC6749"/> already provides robust baseline protection by requiring</t>
<ul spacing="compact">
<li>confidentiality of the refresh tokens in transit and storage,</li>
<li>the transmission of refresh tokens over TLS-protected connections between
authorization server and client,</li>
<li>the authorization server to maintain and check the binding of a refresh token
to a certain client and authentication of this client during token refresh,
if possible, and</li>
<li>that refresh tokens cannot be generated, modified, or guessed.</li>
</ul>
<t><xref target="RFC6749"/> also lays the foundation for further
(implementation-specific) security measures, such as refresh token expiration and
revocation as well as refresh token rotation by defining respective
error codes and response behaviors.</t>
<t>This specification gives recommendations beyond the scope of
<xref target="RFC6749"/> and clarifications.</t>
</section>
<section anchor="recommendations-1"><name>Recommendations</name>
<t>Authorization servers MUST <bcp14>MUST</bcp14> determine, based on a risk assessment,
whether to issue refresh tokens to a certain client. If the
authorization server decides not to issue refresh tokens, the client
MAY
<bcp14>MAY</bcp14> obtain a new access token by utilizing other grant types, such as the
authorization code grant type. In such a case, the authorization
server may utilize cookies and persistent grants to optimize the user
experience.</t>
<t>If refresh tokens are issued, those refresh tokens MUST <bcp14>MUST</bcp14> be bound to
the scope and resource servers as consented by the resource owner.
This is to prevent privilege escalation by the legitimate client and reduce
the impact of refresh token leakage.</t>
<t>For confidential clients, <xref target="RFC6749"/> already requires that refresh
tokens can only be used by the client for which they were issued.</t>
<t>Authorization servers MUST <bcp14>MUST</bcp14> utilize one of these methods to
detect refresh token replay by malicious actors for public clients:</t>
<ul>
<li><strong>Sender-constrained refresh tokens:</strong> the authorization server
cryptographically binds the refresh token to a certain client
instance, e.g., by utilizing <xref target="RFC8705"/> or <xref target="RFC9449"/>.</li>
<li><t><strong>Refresh token rotation:</strong> the authorization server issues a new
refresh token with every access token refresh response. The
previous refresh token is invalidated invalidated, but information about the
relationship is retained by the authorization server. If a refresh
token is compromised and subsequently used by both the attacker
and the legitimate client, one of them will present an invalidated
refresh token, which will inform the authorization server of the
breach. The authorization server cannot determine which party
submitted the invalid refresh token, but it will revoke the
active refresh token. This stops the attack at the cost of forcing
the legitimate client to obtain a fresh authorization grant.</t>
<t>Implementation note: The grant to which a refresh token belongs
may be encoded into the refresh token itself. This can enable an
authorization server to efficiently determine the grant to which a
refresh token belongs, and by extension, all refresh tokens that
need to be revoked. Authorization servers MUST <bcp14>MUST</bcp14> ensure the
integrity of the refresh token value in this case, for example,
using signatures.</t>
</li>
</ul>
<t>Authorization servers MAY <bcp14>MAY</bcp14> revoke refresh tokens automatically in case
of a security event, such as:</t>
<ul spacing="compact">
<li>password change</li> change or</li>
<li>logout at the authorization server</li> server.</li>
</ul>
<t>Refresh tokens SHOULD <bcp14>SHOULD</bcp14> expire if the client has been inactive for some
time, i.e., the refresh token has not been used to obtain fresh access
tokens for some time. The expiration time is at the discretion of the
authorization server. It might be a global value or determined based
on the client policy or the grant associated with the refresh token
(and its sensitivity).</t>
</section>
</section>
<section anchor="client_impersonating"><name>Client Impersonating Resource Owner</name>
<t>Resource servers may make access control decisions based on the identity of a
resource owner for which an access token was issued, or based on the identity of
a client in the client credentials grant. For example, <xref target="RFC9068"/> (JSON Web
Token (JWT) Profile for OAuth 2.0 Access Tokens) describes a data structure for
access tokens containing a <tt>sub</tt> claim defined as follows:</t>
<blockquote><t>In
<blockquote>
<t>
In cases
of access tokens obtained through grants where a resource owner is
involved, such as the authorization code grant, the value of <tt>sub</tt> SHOULD "sub"
<bcp14>SHOULD</bcp14> correspond to the subject identifier of the resource owner.
In cases of access tokens obtained through grants where no
resource owner is involved, such as the client credentials grant,
the value of <tt>sub</tt> SHOULD "sub" <bcp14>SHOULD</bcp14> correspond to an identifier the
authorization server uses to indicate the client application.</t>
</blockquote><t>If application.
</t>
</blockquote>
<t>If both options are possible, a resource server may mistake a client's identity
for the identity of a resource owner. For example, if a client is able to choose
its own <tt>client_id</tt> during registration with the authorization server, a
malicious client may set it to a value identifying a resource owner (e.g., a
<tt>sub</tt> value if OpenID Connect is used). If the resource server cannot properly
distinguish between access tokens obtained with involvement of the resource
owner and those without, the client may accidentally be able to access resources
belonging to the resource owner.</t>
<t>This attack potentially affects not only implementations using <xref target="RFC9068"/>, but
also similar, bespoke solutions.</t>
<section anchor="client_impersonating_countermeasures"><name>Countermeasures</name>
<t>Authorization
<!--[rfced] What is "the sub claim shown above" referring to? May a
section number be added?
Original:
Authorization servers SHOULD NOT allow clients to influence their
client_id or any claim that could cause confusion with a genuine
resource owner if a common namespace for client IDs and user
identifiers exists, such as in the sub claim shown above.
-->
<t>Authorization servers <bcp14>SHOULD NOT</bcp14> allow clients to influence their <tt>client_id</tt> or
any claim that could cause confusion with a genuine resource owner if a common
namespace for client IDs and user identifiers exists, such as in the <tt>sub</tt> claim
shown above. Where this cannot be avoided, authorization servers MUST <bcp14>MUST</bcp14> provide
other means for the resource server to distinguish between the two types of
access tokens.</t>
</section>
</section>
<section anchor="clickjacking"><name>Clickjacking</name>
<t>As described in Section 4.4.1.9 of <xref target="RFC6819"/>, target="RFC6819" sectionFormat="of" section="4.4.1.9"/>, the authorization request is
susceptible to clickjacking attacks, also called user interface redressing. In
such an attack, an attacker embeds the authorization endpoint user interface in
an innocuous context. A user believing to interact with that context, for
example, by clicking on buttons, inadvertently interacts with the authorization
endpoint user interface instead. The opposite can be achieved as well: A user
believing to interact with the authorization endpoint might inadvertently type a
password into an attacker-provided input field overlaid over the original user
interface. Clickjacking attacks can be designed such that users can hardly
notice the attack, for example example, using almost invisible iframes overlaid on top of
other elements.</t>
<t>An attacker can use this vector to obtain the user's authentication credentials,
change the scope of access granted to the client, and potentially access the
user's resources.</t>
<t>Authorization servers MUST <bcp14>MUST</bcp14> prevent clickjacking attacks. Multiple
countermeasures are described in <xref target="RFC6819"/>, including the use of the
X-Frame-Options HTTP response header field and frame-busting
JavaScript. In addition to those, authorization servers SHOULD <bcp14>SHOULD</bcp14> also
use Content Security Policy (CSP) level 2 <xref target="W3C.CSP-2"/> or greater.</t>
<t>To be effective, CSP must be used on the authorization endpoint and,
if applicable, other endpoints used to authenticate the user and
authorize the client (e.g., the device authorization endpoint, login
pages, error pages, etc.). This prevents framing by unauthorized
origins in user agents that support CSP. The client MAY <bcp14>MAY</bcp14> permit being
framed by some other origin than the one used in its redirection
endpoint. For this reason, authorization servers SHOULD <bcp14>SHOULD</bcp14> allow
administrators to configure allowed origins for particular clients
and/or for clients to register these dynamically.</t>
<t>Using CSP allows authorization servers to specify multiple origins in
a single response header field and to constrain these using flexible
patterns (see <xref target="W3C.CSP-2"/> for details). Level 2 of this standard CSP provides
a robust mechanism for protecting against clickjacking by using
policies that restrict the origin of frames (using (by using <tt>frame-ancestors</tt>)
together with those that restrict the sources of scripts allowed to
execute on an HTML page (by using <tt>script-src</tt>). A non-normative
example of such a policy is shown in the following listing:</t>
<artwork><![CDATA[HTTP/1.1
<sourcecode><![CDATA[
HTTP/1.1 200 OK
Content-Security-Policy: frame-ancestors https://ext.example.org:8000
Content-Security-Policy: script-src 'self'
X-Frame-Options: ALLOW-FROM https://ext.example.org:8000
...
]]>
</artwork>
]]></sourcecode>
<t>Because some user agents do not support <xref target="W3C.CSP-2"/>, this technique
SHOULD
<bcp14>SHOULD</bcp14> be combined with others, including those described in
<xref target="RFC6819"/>, unless such legacy user agents are explicitly unsupported
by the authorization server. Even in such cases, additional
countermeasures SHOULD <bcp14>SHOULD</bcp14> still be employed.</t>
</section>
<section anchor="rec_ibc"><name>Attacks on In-Browser Communication Flows</name>
<t>If the authorization response is sent with in-browser communication techniques
like postMessage <xref target="WHATWG.postmessage_api"/> instead of HTTP redirects, messages may
inadvertently be sent to malicious origins or injected from malicious origins.</t>
<section anchor="examples"><name>Examples</name>
<t>The following non-normative pseudocode examples of attacks using in-browser
communication are described in <xref target="research.rub"/>:</t> target="research.rub"/>.</t>
<section anchor="insufficient-limitation-of-receiver-origins"><name>Insufficient Limitation of Receiver Origins</name>
<t>When sending the authorization response or token response via
postMessage, the authorization server sends the response to the wildcard
origin "*" instead of the client's origin. When the window to which the
response is sent is controlled by an attacker, the attacker can read the
response.</t>
<artwork><![CDATA[window.opener.postMessage(
<sourcecode><![CDATA[
window.opener.postMessage(
{
code: "ABC",
state: "123"
},
"*" // any website in the opener window can receive the message
)
]]>
</artwork>
]]></sourcecode>
</section>
<section anchor="insufficient-uri-validation"><name>Insufficient URI Validation</name>
<t>When sending the authorization response or token response via
postMessage, the authorization server may not check the
receiver origin against the redirect URI and instead, for example, may send
the response to an origin provided by an attacker. This is analogous to
the attack described in <xref target="insufficient_uri_validation"/>.</t>
<artwork><![CDATA[window.opener.postMessage(
<sourcecode><![CDATA[
window.opener.postMessage(
{
code: "ABC",
state: "123"
},
"https://attacker.example" // attacker-provided value
)
]]>
</artwork>
]]></sourcecode>
</section>
<section anchor="injection-after-insufficient-validation-of-sender-origin"><name>Injection after Insufficient Validation of Sender Origin</name>
<t>A client that expects the authorization response or token response via
postMessage may not validate the sender origin of the message. This
may allow an attacker to inject an authorization response or token response
into the client.</t>
<t>In the case of a maliciously injected authorization response, the attack
is a variant of the CSRF attacks described in <xref target="csrf"/>. The
countermeasures described in <xref target="csrf"/> apply to this attack as well.</t>
<t>In the case of a maliciously injected token response, sender-constrained
access tokens as described in <xref target="pop_tokens"/> may prevent the attack under
some circumstances, but additional countermeasures as described next in <xref target="recommendations-1-1"/> are
generally required.</t>
</section>
</section>
<section anchor="recommendations-1-1"><name>Recommendations</name>
<t>When comparing client receiver origins against pre-registered origins,
authorization servers MUST <bcp14>MUST</bcp14> utilize exact string matching as described in
<xref target="iuv_countermeasures"/>. Authorization servers MUST <bcp14>MUST</bcp14> send postMessages to
trusted client receiver origins, as shown in the following, non-normative example:</t>
<artwork><![CDATA[window.opener.postMessage(
<sourcecode><![CDATA[
window.opener.postMessage(
{
code: "ABC",
state: "123"
},
"https://client.example" // use explicit client origin
)
]]>
</artwork>
]]></sourcecode>
<t>Wildcard origins like "*" in postMessage MUST NOT <bcp14>MUST NOT</bcp14> be used used, as attackers can use them
to leak a victim's in-browser message to malicious origins.
Both measures contribute to the prevention of leakage of authorization codes and
access tokens (see <xref target="insufficient_uri_validation"/>).</t>
<t>Clients MUST <bcp14>MUST</bcp14> prevent injection of in-browser messages on the client
receiver endpoint. Clients MUST <bcp14>MUST</bcp14> utilize exact string matching to compare
the initiator origin of an in-browser message with the authorization
server origin, as shown in the following, non-normative example:</t>
<artwork><![CDATA[window.addEventListener("message",
<sourcecode><![CDATA[
window.addEventListener("message", (e) => {
// validate exact authorization server origin
if (e.origin === "https://honest.as.example") {
// process e.data.code and e.data.state
}
})
]]>
</artwork>
]]></sourcecode>
<t>Since in-browser communication flows only apply a different communication
technique (i.e., postMessage instead of HTTP redirect), all measures protecting
the authorization response listed in <xref target="rec_redirect"/> MUST <bcp14>MUST</bcp14> be applied equally.</t>
</section>
</section>
</section>
<section anchor="Acknowledgements"><name>Acknowledgements</name>
<t>We would like to thank
Brock Allen,
Annabelle Richard Backman,
Dominick Baier,
Vittorio Bertocci,
Brian Campbell,
Bruno Crispo,
William Dennis,
George Fletcher,
Matteo Golinelli,
Dick Hardt,
Joseph Heenan,
Pedram Hosseyni,
Phil Hunt,
Tommaso Innocenti,
Louis Jannett,
Jared Jennings,
Michael B. Jones,
Engin Kirda,
Konstantin Lapine,
Neil Madden,
Christian Mainka,
Jim Manico,
Nov Matake,
Doug McDorman,
Ali Mirheidari,
Vladislav Mladenov,
Karsten Meyer zu Selhausen,
Kaan Onarioglu,
Aaron Parecki,
Michael Peck,
Johan Peeters,
Nat Sakimura,
Guido Schmitz,
Jörg Schwenk,
Rifaat Shekh-Yusef,
Travis Spencer,
Petteri Stenius,
Tomek Stojecki,
Tim Wuertele,
David Waite and
Hans Zandbelt
for their valuable feedback.</t>
</section>
<section anchor="IANA"><name>IANA Considerations</name>
<t>This draft makes document has no requests to IANA.</t> IANA actions.</t>
</section>
<section anchor="Security"><name>Security Considerations</name>
<t>Security considerations are described in Sections <xref target="recommendations"/>, target="recommendations" format="counter"/>, <xref target="secmodel"/>, target="secmodel" format="counter"/>, and <xref target="attacks_and_mitigations"/>.</t> target="attacks_and_mitigations" format="counter"/>.</t>
</section>
</middle>
<back>
<displayreference target="I-D.bradley-oauth-jwt-encoded-state" to="JWT-ENCODED-STATE"/>
<displayreference target="I-D.ietf-oauth-token-binding" to="TOKEN-BINDING"/>
<displayreference target="I-D.ietf-oauth-v2-1" to="OAUTH-V2.1"/>
<!-- [rfced] Would you like the references to be alphabetized, or
do you prefer the current order? (The sortRefs attribute was
absent in the submitted XML file.)
-->
<references><name>References</name>
<references><name>Normative References</name>
<reference
<referencegroup anchor="BCP195" target="https://www.rfc-editor.org/info/bcp195">
<front>
<title>BCP195</title>
<author>
<organization>IETF</organization>
</author>
</front>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8996.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/>
</referencegroup>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6750.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6819.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7521.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7523.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8252.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8414.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8705.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9068.xml"/>
</references>
<references><name>Informative References</name>
<!-- [I-D.bradley-oauth-jwt-encoded-state] IESG state: Expired as of 06/17/24-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.bradley-oauth-jwt-encoded-state.xml"/>
<!-- [I-D.ietf-oauth-token-binding] IESG state: Expired as of 06/17/24-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-token-binding.xml"/>
<!-- [I-D.ietf-oauth-v2-1] IESG state: I-D Exists as of 06/17/24-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-v2-1.xml"/>
<reference anchor="OAuth.Post" target="https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html">
<front>
<title>OAuth 2.0 Form Post Response Mode</title>
<author fullname="Mike Jones" initials="M." surname="Jones">
<organization>Microsoft</organization>
</author>
<author fullname="Brian Campbell" initials="B." surname="Campbell">
<organization>Ping Identity</organization>
</author>
<date year="2015" month="April" day="27"/>
</front>
<refcontent>The OpenID Foundation</refcontent>
</reference>
<reference anchor="OAuth.Responses" target="https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html">
<front>
<title>OAuth 2.0 Multiple Response Type Encoding Practices</title>
<author fullname="Breno de Medeiros" initials="B." surname="de Medeiros"> Medeiros" role="editor">
<organization>Google</organization>
</author>
<author fullname="Mihai Scurtescu" initials="M." surname="Scurtescu">
<organization>Google</organization>
</author>
<author fullname="Peter Tarjan" surname="Tarjan">
<organization>Facebook</organization>
</author>
<author fullname="Mike Jones" initials="M." surname="Jones">
<organization>Microsoft</organization>
</author>
<date year="2014" month="Feb" day="25"/>
</front>
<refcontent>The OpenID Foundation</refcontent>
</reference>
<reference anchor="OpenID.Core" target="https://openid.net/specs/openid-connect-core-1_0.html">
<front>
<title>OpenID Connect Core 1.0 incorporating errata set 2</title>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization>NAT.Consulting</organization>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization>Yubico</organization>
</author>
<author fullname="Mike Jones" initials="M." surname="Jones">
<organization>Self-Issued Consulting</organization>
</author>
<author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
<organization>Google</organization>
</author>
<author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
<organization>Disney</organization>
</author>
<date year="2023" month="Dec" day="15"/>
</front>
<refcontent>The OpenID Foundation</refcontent>
</reference>
<reference anchor="OpenID.Discovery" target="https://openid.net/specs/openid-connect-discovery-1_0.html">
<front>
<title>OpenID Connect Discovery 1.0 incorporating errata set 2</title>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization>NAT.Consulting</organization>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization>Yubico</organization>
</author>
<author fullname="Mike Jones" initials="M." surname="Jones">
<organization>Self-Issued Consulting</organization>
</author>
<author fullname="Edmund Jay" initials="E." surname="Jay">
<organization>Illumila</organization>
</author>
<date year="2023" month="Dec" day="15"/>
</front>
<refcontent>The OpenID Foundation</refcontent>
</reference>
<reference anchor="OpenID.JARM" target="https://openid.net/specs/openid-financial-api-jarm.html">
<front>
<title>Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)</title>
<author fullname="Torsten Lodderstedt" initials="T." surname="Lodderstedt">
<organization>Yes</organization>
</author>
<author fullname="Brian Campbell" initials="B." surname="Campbell">
<organization>Ping</organization>
</author>
<date year="2018" month="Oct" day="17"/>
</front>
<refcontent>The OpenID Foundation</refcontent>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7591.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7636.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8707.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9101.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9207.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9396.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9440.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9449.xml"/>
<!-- [rfced] FYI, we have updated this reference to use the the most current
date. Please let us know if you prefer otherwise.
Original:
[W3C.CSP-2]
West, M., Barth, A., and D. Veditz, "Content Security
Policy Level 2", July 2015, <https://www.w3.org/TR/CSP2>.
Current:
[W3C.CSP-2]
West, M., Barth, A., and D. Veditz, "Content Security
Policy Level 2", W3C Recommendation, December 2016,
<https://www.w3.org/TR/2016/REC-CSP2-20161215/>. Latest
version available at <https://www.w3.org/TR/CSP2/>.
-->
<reference anchor="W3C.CSP-2" target="https://www.w3.org/TR/CSP2"> target="https://www.w3.org/TR/2016/REC-CSP2-20161215/">
<front>
<title>Content Security Policy Level 2</title>
<author initials="M." surname="West"/>
<author initials="A." surname="Barth"/>
<author initials="D." surname="Veditz"/>
<date year="2015" month="July"/> year="2016" month="December"/>
</front>
<refcontent>W3C Recommendation</refcontent>
<annotation>Latest version available at <eref target="https://www.w3.org/TR/CSP2/" brackets="angle" />.</annotation>
</reference>
<reference anchor="W3C.WebAuthn" target="https://www.w3.org/TR/2021/REC-webauthn-2-20210408/">
<front>
<title>Web Authentication: An API for accessing Public Key Credentials Level 2</title>
<author fullname="Jeff Hodges" initials="J." surname="Hodges">
<organization>Google</organization>
</author>
<author fullname="J.C. Jones" initials="J.C." surname="Jones">
<organization>Mozilla</organization>
</author>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization>Microsoft</organization>
</author>
<author fullname="Akshay Kumar" initials="A." surname="Kumar">
<organization>Microsoft</organization>
</author>
<author fullname="Emil Lundberg" initials="E." surname="Lundberg">
<organization>Yubico</organization>
</author>
<date year="2021" month="Apr" day="08"/>
</front>
<refcontent>W3C Recommendation</refcontent>
<annotation>Latest version available at <eref target="https://www.w3.org/TR/webauthn-2/" brackets="angle"/>.</annotation>
</reference>
<reference anchor="W3C.WebCrypto" target="https://www.w3.org/TR/2017/REC-WebCryptoAPI-20170126/">
<front>
<title>Web Cryptography API</title>
<author fullname="Mark Watson" initials="M." surname="Watson"> surname="Watson" role="editor">
<organization>Netflix</organization>
</author>
<date year="2017" month="January" day="26"/>
</front>
<refcontent>W3C Recommendation</refcontent>
<annotation>Latest version available at <eref target="https://www.w3.org/TR/WebCryptoAPI/" brackets="angle"/>.</annotation>
</reference>
<!-- [rfced] FYI, the original URL provided for
[W3C.webappsec-referrer-policy] directs to a W3C Editor's Draft with a
date of 1 November 2024. However, the date listed on the reference is 20
April 2017, which does not match any of the dates of the published
versions. We have updated the reference as follows so it's to the latest
published version; please let us know if you prefer otherwise.
Original:
[W3C.webappsec-referrer-policy]
Eisinger, J. and E. Stark, "Referrer Policy", 20 April
2017, <https://w3c.github.io/webappsec-referrer-policy>.
Current:
[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/>.
-->
<reference anchor="W3C.webappsec-referrer-policy" target="https://w3c.github.io/webappsec-referrer-policy"> target="https://www.w3.org/TR/2017/CR-referrer-policy-20170126/">
<front>
<title>Referrer Policy</title>
<author initials="J." surname="Eisinger">
<organization>Google Inc.</organization>
</author>
<author initials="E." surname="Stark">
<organization>Google Inc.</organization>
</author>
<date year="2017" month="April" day="20"/> month="January" day="26"/>
</front>
<annotation>Latest version available at <eref target="https://www.w3.org/TR/referrer-policy/" brackets="angle"/>.</annotation>
</reference>
<reference anchor="WHATWG.CORS" target="https://fetch.spec.whatwg.org/#http-cors-protocol">
<front>
<title>Fetch Standard: CORS
<title>CORS protocol</title>
<author/>
<date/>
<author>
<organization>WHATWG</organization>
</author>
<date day="17" month="June" year="2024"/>
</front>
<refcontent>Fetch: Living Standard, Section 3.2</refcontent>
</reference>
<reference anchor="WHATWG.postmessage_api" target="https://html.spec.whatwg.org/multipage/web-messaging.html#web-messaging">
<front>
<title>HTML Living Standard: Cross-document
<title>Cross-document messaging</title>
<author/>
<date/>
<author>
<organization>WHATWG</organization>
</author>
<date day="19" month="August" year="2024"/>
</front>
<refcontent>HTML: Living Standard, Section 9.3</refcontent>
</reference>
<reference anchor="arXiv.1508.04324v2" target="https://arxiv.org/abs/1508.04324v2/">
<front>
<title>On the security of modern Single Sign-On Protocols: Second-Order Vulnerabilities in OpenID Connect</title>
<author fullname="Vladislav Mladenov" initials="V." surname="Mladenov">
<organization/>
</author>
<author fullname="Christian Mainka" initials="C." surname="Mainka">
<organization/>
</author>
<author fullname="Jörg Schwenk" initials="J." surname="Schwenk">
<organization/>
</author>
<date year="2016" month="January" day="7"/>
</front>
<refcontent>arXiv:1508.04324v2</refcontent>
<seriesInfo name="arXiv" value="1508.04324v2"/> name="DOI" value="10.48550/arXiv.1508.04324"/>
</reference>
<reference anchor="arXiv.1601.01229" target="https://arxiv.org/abs/1601.01229/">
<front>
<title>A Comprehensive Formal Security Analysis of OAuth 2.0</title>
<author fullname="Daniel Fett" initials="D." surname="Fett">
<organization/>
</author>
<author fullname="Ralf Küsters" initials="R." surname="Küsters">
<organization/>
</author>
<author fullname="Guido Schmitz" initials="G." surname="Schmitz">
<organization/>
</author>
<date year="2016" month="January" day="6"/>
</front>
<refcontent>arXiv:1601.01229</refcontent>
<seriesInfo name="arXiv" value="1601.01229"/> name="DOI" value="10.48550/arXiv.1601.01229"/>
</reference>
<reference anchor="arXiv.1704.08539" target="https://arxiv.org/abs/1704.08539/">
<front>
<title>The Web SSO Standard OpenID Connect: In-Depth Formal Security Analysis and Security Guidelines</title>
<author fullname="Daniel Fett" initials="D." surname="Fett">
<organization/>
</author>
<author fullname="Ralf Küsters" initials="R." surname="Küsters">
<organization/>
</author>
<author fullname="Guido Schmitz" initials="G." surname="Schmitz">
<organization/>
</author>
<date year="2017" month="April" day="27"/>
</front>
<refcontent>arXiv:1704.08539</refcontent>
<seriesInfo name="arXiv" value="1704.08539"/> name="DOI" value="10.48550/arXiv.1704.08539"/>
</reference>
<reference anchor="arXiv.1901.11520" target="https://arxiv.org/abs/1901.11520/">
<front>
<title>An Extensive Formal Security Analysis of the OpenID Financial-grade API</title>
<author fullname="Daniel Fett" initials="D." surname="Fett">
<organization/>
</author>
<author fullname="Pedram Hosseyni" initials="P." surname="Hosseyni">
<organization/>
</author>
<author fullname="Ralf Küsters" initials="R." surname="Küsters">
<organization/>
</author>
<date year="2019" month="January" day="31"/>
</front>
<refcontent>arXiv:1901.11520</refcontent>
<seriesInfo name="arXiv" value="1901.11520"/> name="DOI" value="10.48550/arXiv.1901.11520"/>
</reference>
<reference anchor="bug.chromium" target="https://issues.chromium.org/issues/40076763">
<front>
<title>Referer header includes URL fragment when opening link using New Tab</title>
<author/>
<date/>
</front>
<refcontent>Chromium Issue Tracker, Issue ID: 40076763</refcontent>
</reference>
<reference anchor="owasp.redir" target="https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html">
<front>
<title>OWASP Cheat Sheet Series - Unvalidated
<title>Unvalidated Redirects and Forwards</title>
<author/> Forwards Cheat Sheet</title>
<author>
<organization>OWASP Foundation</organization>
</author>
<date/>
</front>
<refcontent>OWASP Cheat Sheet Series</refcontent>
</reference>
<!-- [rfced] URL and title mismatch:
The URL provided for [research.cmu] is for a page titled
"The Devil is in the (Implementation) Details: An Empirical Analysis of
OAuth SSO Systems", but the title provided is "OAuth Demystified for
Mobile Application Developers", which is already referenced as
[research.ubc].
So, perhaps for [research.cmu] this URL was intended?
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/OAuthDemystified.pdf
If so, we can update the reference accordingly.
Original:
[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>.
Perhaps you intended:
[research.cmu2]
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>.
-->
<reference anchor="research.cmu" target="https://css.csail.mit.edu/6.858/2012/readings/oauth-sso.pdf">
<front>
<title>OAuth Demystified for Mobile Application Developers</title>
<author fullname="Eric Chen" initials="E." surname="Chen">
<organization abbrev="CMU">Carnegie Mellon University</organization>
</author>
<author fullname="Yutong Pei" initials="Y." surname="Pei">
<organization abbrev="CMU">Carnegie Mellon University</organization>
</author>
<author fullname="Shuo Chen" initials="S." surname="Chen">
<organization abbrev="MR">Microsoft Research</organization>
</author>
<author fullname="Yuan Tian" initials="Y." surname="Tian">
<organization abbrev="CMU">Carnegie Mellon University</organization>
</author>
<author fullname="Robert Kotcher" initials="R." surname="Kotcher">
<organization abbrev="CMU">Carnegie Mellon University</organization>
</author>
<author fullname="Patrick Tague" initials="P." surname="Tague">
<organization abbrev="CMU">Carnegie Mellon University</organization>
</author>
<date year="2014" month="November"/>
</front>
<format type="pdf" target="https://css.csail.mit.edu/6.858/2012/readings/oauth-sso.pdf"/>
</reference>
<!-- Below is the updated XML if the authors accept the change to correct
the URL.
<reference anchor="research.cmu2" target="https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/OAuthDemystified.pdf">
<front>
<title>OAuth Demystified for Mobile Application Developers</title>
<author fullname="Eric Chen" initials="E." surname="Chen">
<organization abbrev="CMU">Carnegie Mellon University</organization>
</author>
<author fullname="Yutong Pei" initials="Y." surname="Pei">
<organization abbrev="CMU">Carnegie Mellon University</organization>
</author>
<author fullname="Shuo Chen" initials="S." surname="Chen">
<organization abbrev="MR">Microsoft Research</organization>
</author>
<author fullname="Yuan Tian" initials="Y." surname="Tian">
<organization abbrev="CMU">Carnegie Mellon University</organization>
</author>
<author fullname="Robert Kotcher" initials="R." surname="Kotcher">
<organization abbrev="CMU">Carnegie Mellon University</organization>
</author>
<author fullname="Patrick Tague" initials="P." surname="Tague">
<organization abbrev="CMU">Carnegie Mellon University</organization>
</author>
<date year="2014" month="November"/>
</front>
<refcontent>CCS '14: Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, pp. 892-903</refcontent>
<seriesInfo name="DOI" value="10.1145/2660267.2660323"/>
</reference>
-->
<reference anchor="research.jcs_14" target="https://www.doc.ic.ac.uk/~maffeis/papers/jcs14.pdf">
<front>
<title>Discovering concrete attacks on website authorization by formal analysis</title>
<author fullname="Chetan Bansal" initials="C." surname="Bansal">
<organization/>
</author>
<author fullname="Karthikeyan Bhargavan" initials="K." surname="Bhargavan">
<organization/>
</author>
<author fullname="Antoine Delignat-Lavaud" initials="A." surname="Delignat-Lavaud">
<organization/>
</author>
<author fullname="Sergio Maffeis" initials="S." surname="Maffeis">
<organization/>
</author>
<date year="2014" month="April" day="23"/>
</front>
<format type="pdf" target="https://www.doc.ic.ac.uk/~maffeis/papers/jcs14.pdf"/>
<refcontent>Journal of Computer Security, vol. 22, no. 4, pp. 601-657</refcontent>
<seriesInfo name="DOI" value="10.3233/JCS-140503"/>
</reference>
<reference anchor="research.rub" target="https://distinct-sso.com/paper.pdf"> target="https://dl.acm.org/doi/pdf/10.1145/3548606.3560692">
<front>
<title>DISTINCT: Identity Theft using In-Browser Communications in Dual-Window Single Sign-On</title>
<author fullname="Louis Jannett" initials="L." surname="Jannett">
<organization/>
</author>
<author fullname="Vladislav Mladenov" initials="V." surname="Mladenov">
<organization/>
</author>
<author fullname="Christian Mainka" initials="C." surname="Mainka">
<organization/>
</author>
<author fullname="Jörg Schwenk" initials="J." surname="Schwenk">
<organization/>
</author>
<date year="2022" month="November" day="7"/>
</front>
<refcontent>CCS '22: Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security</refcontent>
<seriesInfo name="DOI" value="10.1145/3548606.3560692"/>
</reference>
<reference anchor="research.rub2" target="https://www.nds.rub.de/media/ei/arbeiten/2021/05/03/masterthesis.pdf">
<front>
<title>Security Analysis of Real-Life OpenID Connect Implementations</title>
<author fullname="Christian Fries" initials="C." surname="Fries">
<organization/>
</author>
<date year="2020" month="December" day="20"/>
</front>
<refcontent>Master's thesis, Ruhr-Universität Bochum (RUB)</refcontent>
</reference>
<reference anchor="research.ubc" target="https://passwordresearch.com/papers/paper267.html"> target="https://css.csail.mit.edu/6.858/2012/readings/oauth-sso.pdf">
<front>
<title>The Devil is in the (Implementation) Details: An Empirical Analysis of OAuth SSO Systems</title>
<author fullname="San-Tsai Sun" initials="S.-T." surname="Sun">
<organization abbrev="UBC">University of British Columbia</organization>
</author>
<author fullname="Konstantin Beznosov" initials="K." surname="Beznosov">
<organization abbrev="UBC">University of British Columbia</organization>
</author>
<date year="2012" month="October"/>
</front>
<format type="HTML" target="https://passwordresearch.com/papers/paper267.html"/>
<refcontent>Proceedings of the 2012 ACM conference on Computer and communications security (CCS '12), pp. 378-390</refcontent>
<seriesInfo name="DOI" value="10.1145/2382196.2382238"/>
</reference>
<!-- [rfced] FYI, we updated the URLs for the following
references, as detailed below. Please let us know if you
prefer otherwise.
- for [research.rub] from
https://distinct-sso.com/paper.pdf to
https://dl.acm.org/doi/pdf/10.1145/3548606.3560692
This is the PDF file that is found at the target page of the DOI
(https://dl.acm.org/doi/10.1145/3548606.3560692).
- for [research.ubc] from
https://passwordresearch.com/papers/paper267.html to
https://css.csail.mit.edu/6.858/2012/readings/oauth-sso.pdf
- for [research.ude1] from
https://www.eecis.udel.edu/~hnw/paper/ccs16a.pdf to
https://dl.acm.org/doi/pdf/10.1145/2976749.2978387
to avoid referencing a personal web space.
-->
<reference anchor="research.udel" target="https://www.eecis.udel.edu/~hnw/paper/ccs16a.pdf"> target="https://dl.acm.org/doi/pdf/10.1145/2976749.2978387">
<front>
<title>All Your DNS Records Point to Us: Understanding the Security Threats of Dangling DNS Records</title>
<author fullname="Daiping Liu" initials="D." surname="Liu"/>
<author fullname="Shuai Hao" initials="S." surname="Hao"/>
<author fullname="Haining Wang" initials="H." surname="Wang"/>
<date year="2016" month="October" day="24"/>
</front>
<refcontent>CCS '16: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 1414-1425</refcontent>
<seriesInfo name="DOI" value="10.1145/2976749.2978387"/>
</reference>
</references>
</references>
<section anchor="document-history"><name>Document History</name>
<t>[[ To be removed from the final specification ]]</t>
<t>-29</t>
<ul spacing="compact">
<li>Fix broken reference</li>
</ul>
<t>-28</t>
<ul spacing="compact">
<li>Various editorial fixes</li>
<li>Address feedback from IESG ballot</li>
</ul>
<t>-27</t>
<ul spacing="compact">
<li>Mostly editorial feedback from Microsoft incorporated</li>
<li>Feedback from SECDIR review incorporated</li>
</ul>
<t>-26</t>
<ul spacing="compact">
<li>Feedback from ARTART review incorporated</li>
<li>Gen-ART review (typo fixes)</li>
</ul>
<t>-25</t>
<ul spacing="compact">
<li>Shepherd's writeup feedback: Removed discussion on outdated POP approaches</li>
<li>Shepherd's writeup feedback: Clarify relationship numbered="false" anchor="Acknowledgements"><name>Acknowledgements</name>
<t>We would like to other document.</li>
<li>Shepherd's writeup feedback: Expand abbreviations</li>
<li>Shepherd's writeup feedback: Better explain attacker model</li>
<li>Shepherd's writeup feedback: Various editorial changes</li>
<li>AD review: Mention updated documents thank
<contact fullname="Brock Allen"/>,
<contact fullname="Annabelle Richard Backman"/>,
<contact fullname="Dominick Baier"/>,
<contact fullname="Vittorio Bertocci"/>,
<contact fullname="Brian Campbell"/>,
<contact fullname="Bruno Crispo"/>,
<contact fullname="William Dennis"/>,
<contact fullname="George Fletcher"/>,
<contact fullname="Matteo Golinelli"/>,
<contact fullname="Dick Hardt"/>,
<contact fullname="Joseph Heenan"/>,
<contact fullname="Pedram Hosseyni"/>,
<contact fullname="Phil Hunt"/>,
<contact fullname="Tommaso Innocenti"/>,
<contact fullname="Louis Jannett"/>,
<contact fullname="Jared Jennings"/>,
<contact fullname="Michael B. Jones"/>,
<contact fullname="Engin Kirda"/>,
<contact fullname="Konstantin Lapine"/>,
<contact fullname="Neil Madden"/>,
<contact fullname="Christian Mainka"/>,
<contact fullname="Jim Manico"/>,
<contact fullname="Nov Matake"/>,
<contact fullname="Doug McDorman"/>,
<contact fullname="Karsten Meyer zu Selhausen"/>,
<contact fullname="Ali Mirheidari"/>,
<contact fullname="Vladislav Mladenov"/>,
<contact fullname="Kaan Onarioglu"/>,
<contact fullname="Aaron Parecki"/>,
<contact fullname="Michael Peck"/>,
<contact fullname="Johan Peeters"/>,
<contact fullname="Nat Sakimura"/>,
<contact fullname="Guido Schmitz"/>,
<contact fullname="Jörg Schwenk"/>,
<contact fullname="Rifaat Shekh-Yusef"/>,
<contact fullname="Travis Spencer"/>,
<contact fullname="Petteri Stenius"/>,
<contact fullname="Tomek Stojecki"/>,
<contact fullname="David Waite"/>,
<contact fullname="Tim Würtele"/>, and
<contact fullname="Hans Zandbelt"/>
for their valuable feedback.</t>
</section>
</back>
<!--[rfced] Terminology
attacker A1 vs. Attacker (A1)
This appeared in abstract</li>
<li>AD review: Fix HTTP reference</li>
<li>AD review: Clarification both forms in the attacker model</li>
<li>AD review: Various editorial and minor changes</li>
</ul>
<t>-24</t>
<ul spacing="compact">
<li>Some feedback from shepherd's writeup incorporated</li>
<li>Cleaned up references</li>
<li>Clarification on mix-up attack</li>
<li>Add researcher names to acknowledgements</li>
<li>Removed sentence stating that only MTLS is standardized; DPoP is now as well</li>
</ul>
<t>-23</t>
<ul spacing="compact">
<li>Added CORS considerations</li>
<li>Reworded <xref target="client_impersonating_countermeasures"/> to be more in line with OAuth 2.1</li>
<li>Editorial changes</li>
<li>Clarifications and original. We have updated references</li>
</ul>
<t>-22</t>
<ul spacing="compact">
<li>Added section on securing in-browser communication</li>
<li>Merged section on phishing via AS into existing section on open redirectors</li>
<li>Restructure and move section on sender-constrained tokens</li>
<li>Mention RFCs for Private Key JWK method</li>
</ul>
<t>-21</t>
<ul spacing="compact">
<li>Improved wording on phishing via AS</li>
</ul>
<t>-20</t>
<ul spacing="compact">
<li>Improved description of authorization code injection attacks and PKCE protection</li>
<li>Removed recommendation for MTLS in discussion (not reflected in actual Recommendations section)</li>
<li>Reworded "placeholder" text in security considerations.</li>
<li>Alphabetized list of names and fixed unicode problem</li>
<li>Explained Clickjacking</li>
<li>Explained Open Redirectors</li>
<li>Clarified references to attacker model by including a link to <xref target="secmodel"/></li>
<li>Clarified description of "CSRF tokens" and reference
to RFC6819</li>
<li>Described that OIDC can prevent access token injection</li>
<li>Updated references</li>
</ul>
<t>-19</t>
<ul spacing="compact">
<li>Changed affiliation of Andrey Labunets</li>
<li>Editorial change to clarify the new recommendations for refresh tokens</li>
</ul>
<t>-18</t>
<ul spacing="compact">
<li>Fix editorial and spelling issues.</li>
<li>Change wording for disallowing HTTP redirect URIs.</li>
</ul>
<t>-17</t>
<ul spacing="compact">
<li>Make the use of metadata RECOMMENDED for both servers and clients</li>
<li>Make announcing PKCE support in metadata the RECOMMENDED way (before: either metadata or deployment-specific way)</li>
<li>AS also MUST NOT expose open redirectors.</li>
<li>Mention that attackers can collaborate.</li>
<li>Update recommendations regarding mix-up defense, building upon <xref target="RFC9207"/>.</li>
<li>Improve description of mix-up attack.</li>
<li>Make HTTPS mandatory for most redirect URIs.</li>
</ul>
<t>-16</t>
<ul spacing="compact">
<li>Make MTLS a suggestion instead of RECOMMENDED.</li>
<li>Add important requirements when using nonce for code injection protection.</li>
<li>Highlight requirements for refresh parentheses throughout; please let us know if you
prefer otherwise.
ID token sender-constraining.</li>
<li>Make PKCE a MUST for public clients.</li>
<li>Describe PKCE Downgrade Attacks and countermeasures.</li>
<li>Allow variable port numbers in localhost redirect URIs as in RFC8252, Section 7.3.</li>
</ul>
<t>-15</t>
<ul spacing="compact">
<li>Update reference to DPoP</li>
<li>Fix reference to RFC8414</li>
<li>Move to xml2rfcv3</li>
</ul>
<t>-14</t>
<ul spacing="compact">
<li>Added info about using CSP to prevent clickjacking</li>
<li>Changes from WGLC feedback</li>
<li>Editorial changes</li>
<li>AS MUST announce PKCE support either in metadata or using deployment-specific ways (before: SHOULD)</li>
</ul>
<t>-13</t>
<ul spacing="compact">
<li>Discourage use of Resource Owner Password Credentials Grant</li>
<li>Added text on client impersonating resource owner</li>
<li>Recommend asymmetric methods for client authentication</li>
<li>Encourage use of PKCE mode "S256"</li>
<li>PKCE may replace state for CSRF protection</li>
<li>AS SHOULD publish PKCE support</li>
<li>Cleaned up discussion on auth code injection</li>
<li>AS MUST support PKCE</li>
</ul>
<t>-12</t>
<ul spacing="compact">
<li>Added vs. ID Token
We have updated attacker model</li>
</ul>
<t>-11</t>
<ul spacing="compact">
<li>Adapted section 2.1.2 to outcome the latter. (There was only one instance of consensus call</li>
<li>more text on refresh token inactivity lowercase.)
-->
<!-- [rfced] In the HTML and implementation note on refresh token replay detection via refresh token rotation</li>
</ul>
<t>-10</t>
<ul spacing="compact">
<li>incorporated feedback by Joseph Heenan</li>
<li>changed occurrences of SHALL to MUST</li>
<li>added PDF outputs, the text on lack of token/cert binding support tokens issued enclosed in <tt> is
in fixed-width font. In the authorization response as justification to not recommend
issuing tokens TXT output, there at all</li>
<li>added requirement to authenticate clients during code exchange
(PKCE or client credential) to 2.1.1.</li>
<li>added section on refresh tokens</li>
<li>editorial enhancements to 2.1.2 based on feedback</li>
</ul>
<t>-09</t>
<ul spacing="compact">
<li>changed text to recommend not to use implicit but code</li>
<li>added section on access token injection</li>
<li>reworked sections 3.1 through 3.3 are no changes to be more specific on implicit
grant issues</li>
</ul>
<t>-08</t>
<ul spacing="compact">
<li>added recommendations re implicit the font,
and token injection</li>
<li>uppercased key words no quotation marks are added.
In the HTML and PDF outputs, the text enclosed in Section 2 according to RFC 2119</li>
</ul>
<t>-07</t>
<ul spacing="compact">
<li>incorporated findings of Doug McDorman</li>
<li>added section on HTTP status codes for redirects</li>
<li>added new section on access token privilege restriction based on
comments from Johan Peeters</li>
</ul>
<t>-06</t>
<ul spacing="compact">
<li>reworked section 3.8.1</li>
<li>incorporated Phil Hunt's feedback</li>
<li>reworked section on mix-up</li>
<li>extended section on code leakage via referrer header to also cover
state leakage</li>
<li>added Daniel Fett as author</li>
<li>replaced <strong> is output in
bold. In the TXT output, the text intended to inform WG discussion by recommendations
to implementors</li>
<li>modified example URLs to conform to RFC 2606</li>
</ul>
<t>-05</t>
<ul spacing="compact">
<li>Completed sections on code leakage via referrer header, attacks enclosed in
browser, mix-up, <strong> appears with an
asterisk (*) before and CSRF</li>
<li>Reworked Code Injection Section</li>
<li>Added reference to OpenID Connect spec</li>
<li>removed refresh token leakage as respective considerations have after.
Please review carefully and let us know if the output is acceptable
or if any updates are needed.
-->
<!-- [rfced] Please consider whether the "type" attribute of any
sourcecode element should be set and/or has been given set correctly.
Specifically, please review the sourcecode elements in section 10.4 Sections 4.1.1,
4.1.2, 4.10.3, 4.16, 4.17.1.1, 4.17.1.2, and 4.17.2. Should the type
be "http-message"?
The current list of RFC 6749</li>
<li>first version on open redirection</li>
<li>incorporated Christian Mainka's review feedback</li>
</ul>
<t>-04</t>
<ul spacing="compact">
<li>Restructured document preferred values for better readability</li>
<li>Added best practices on Token Leakage prevention</li>
</ul>
<t>-03</t>
<ul spacing="compact">
<li>Added section on Access Token Leakage "type" is available at Resource Server</li>
<li>incorporated Brian Campbell's findings</li>
</ul>
<t>-02</t>
<ul spacing="compact">
<li>Folded Mix up and Access Token leakage through a bad AS into new
section for dynamic OAuth threats</li>
<li>reworked dynamic OAuth section</li>
</ul>
<t>-01</t>
<ul spacing="compact">
<li>Added references
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
If the current list does not contain an applicable type, feel free to mitigation methods
suggest additions for token leakage</li>
<li>Added reference consideration. Note that it is also acceptable
to Token Binding for Authorization Code</li>
<li>incorporated feedback of Phil Hunt</li>
<li>fixed numbering issue in attack descriptions in section 2</li>
</ul>
<t>-00 (WG document)</t>
<ul spacing="compact">
<li>turned leave the ID into a WG document "type" attribute not set.
More information on that element and a BCP</li>
<li>Added federated app login as topic attribute:
https://authors.ietf.org/rfcxml-vocabulary#sourcecode
https://authors.ietf.org/rfcxml-vocabulary#type-2
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in Other Topics</li>
</ul>
</section>
</back> more precise language, which is helpful for readers.
For example, please consider whether the following should be updated:
native
-->
</rfc>