Updates to OAuth 2.0 Security Best Current Practice
draft-wuertele-oauth-security-topics-update-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Tim Würtele , Pedram Hosseyni , Kaixuan Luo , Adonis Fung | ||
| Last updated | 2025-06-16 | ||
| Replaced by | draft-ietf-oauth-security-topics-update | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wuertele-oauth-security-topics-update-01
Web Authorization Protocol T. Würtele
Internet-Draft P. Hosseyni
Updates: 6749, 6750, 7521, 7522, 7523, 9700 University of Stuttgart
(if approved) K. Luo
Intended status: Best Current PracticeThe Chinese University of Hong Kong
Expires: 19 December 2025 A. Fung
Samsung Research America
17 June 2025
Updates to OAuth 2.0 Security Best Current Practice
draft-wuertele-oauth-security-topics-update-01
Abstract
This document updates the set of best current security practices for
OAuth 2.0 by extending the security advice given in RFC 6749, RFC
6750, and RFC 9700, to cover new threats that have been discovered
since the former documents have been published.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://SECtim.github.io/draft-wuertele-oauth-security-topics-update/
draft-wuertele-oauth-security-topics-update.html. Status information
for this document may be found at https://datatracker.ietf.org/doc/
draft-wuertele-oauth-security-topics-update/.
Discussion of this document takes place on the Web Authorization
Protocol mailing list (mailto:oauth@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/oauth/. Subscribe at
https://www.ietf.org/mailman/listinfo/oauth/.
Source for this draft and an issue tracker can be found at
https://github.com/SECtim/draft-wuertele-oauth-security-topics-
update.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Würtele, et al. Expires 19 December 2025 [Page 1]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 December 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions and Terminology . . . . . . . . . . . . . . . 3
2. Attacks and Mitigations . . . . . . . . . . . . . . . . . . . 3
2.1. Audience Injection Attacks . . . . . . . . . . . . . . . 4
2.1.1. Attack Description . . . . . . . . . . . . . . . . . 4
2.1.2. Countermeasures . . . . . . . . . . . . . . . . . . . 6
2.2. Updates to Mix-Up Attacks . . . . . . . . . . . . . . . . 8
2.2.1. Updates to "Per-AS Redirect URIs" Mix-Up Variant . . 8
2.2.2. Clarifications on Countermeasures for Mix-Up
Variants . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Attacks in Open Ecosystems . . . . . . . . . . . . . . . 11
2.3.1. OAuth in Open Ecosystems . . . . . . . . . . . . . . 11
2.3.2. Attack Scenario . . . . . . . . . . . . . . . . . . . 12
2.3.3. Mix-Up Attacks Reloaded . . . . . . . . . . . . . . . 13
2.3.4. Client Configuration Confusion Attack . . . . . . . . 16
3. Security Considerations . . . . . . . . . . . . . . . . . . . 20
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Normative References . . . . . . . . . . . . . . . . . . 20
5.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Document History . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Würtele, et al. Expires 19 December 2025 [Page 2]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
1. Introduction
Since the publication of the first OAuth 2.0 Security Best Practices
document [RFC9700], new threats to OAuth 2.0 ecosystems have been
identified. This document therefore serves as an extension of the
original [RFC9700] and is to be read in conjunction with it.
Like [RFC9700] before, this document provides important security
recommendations and it is RECOMMENDED that implementers upgrade their
implementations and ecosystems as soon as feasible.
1.1. Structure
The remainder of this document is organized as follows: Section 2 is
a detailed analysis of the threats and implementation issues that can
be found in the wild (at the time of writing) along with a discussion
of potential countermeasures.
1.2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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 [RFC6749].
// Make sure to update this list once the technical sections below
// are completed.
//
// -- Tim W.
2. Attacks and Mitigations
This section gives a detailed description of new attacks on OAuth
implementations, along with potential countermeasures. Attacks and
mitigations already covered in [RFC9700] are not listed here, except
where clarifications or new recommendations are made. Generally, the
attacks in this section assume a scenario where a client can interact
with multiple authorization servers.
Würtele, et al. Expires 19 December 2025 [Page 3]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
2.1. Audience Injection Attacks
When using signature-based client authentication methods such as
private_key_jwt as defined in [OpenID.Core] or signed JWTs as defined
in [RFC7521] and [RFC7523], a malicious authorization server may be
able to obtain and use a client's authentication credential, enabling
them to impersonate a client towards another honest authorization
server.
2.1.1. Attack Description
The descriptions here follow [research.ust], where additional details
of the attack are laid out. Audience injection attacks require a
client to interact with at least two authorization servers, one of
which is malicious, and to authenticate to both with a signature-
based authentication method using the same key pair. The following
description uses the jwt-bearer client authentication from [RFC7523],
see Section 2.1.1.3 for other affected client authentication methods.
Furthermore, the client needs to be willing to authenticate at an
endpoint other than the token endpoint at the attacker authorization
server (see Section 2.1.1.2).
2.1.1.1. Core Attack Steps
In the following, let H-AS be an honest authorization server and let
A-AS be an attacker-controlled authorization server.
Assume that the authorization servers publish the following URIs for
their token endpoints, for example via mechanisms such as
authorization server metadata [RFC8414] or OpenID Discovery
[OpenID.Discovery]. The exact publication mechanism is not relevant,
as audience injection attacks are also possible on clients with
manually configured authorization server metadata.
Excerpt from H-AS' metadata:
"issuer": "https://honest.com",
"token_endpoint": "https://honest.com/token",
...
Excerpt from A-AS' metadata:
"issuer": "https://attacker.com",
"token_endpoint": "https://honest.com/token",
...
Würtele, et al. Expires 19 December 2025 [Page 4]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
Therefore, the attacker authorization server claims to use the honest
authorization server's token endpoint. Note that the attacker
authorization server does not control this endpoint. The attack then
commences as follows:
1. Client registers at H-AS, and gets assigned a client ID cid.
2. Client registers at A-AS, and gets assigned the same client ID
cid. Note that the client ID is not a secret (Section 2.2 of
[RFC6749]).
Now, whenever the client creates a client assertion for
authentication to A-AS, the assertion consists of a JSON Web Token
(JWT) that is signed by the client and contains, among others, the
following claims:
"iss": "cid",
"sub": "cid",
"aud": "https://honest.com/token"
Due to the malicious use of H-AS' token endpoint in A-AS'
authorization server metadata, the aud claim contains H-AS' token
endpoint. Recall that both A-AS and H-AS registered the client with
client ID cid, and that the client uses the same key pair for
authentication at both authorization servers. Hence, this client
assertion is a valid authentication credential for the client at
H-AS.
The use of the token endpoint to identify the authorization server as
a client assertion's audience even for client assertions that are not
sent to the token endpoint is encouraged, or at least allowed by many
standards, including [RFC7521], [RFC7522], [RFC7523], [RFC9126],
[OpenID.Core], [OpenID.CIBA], and all standards referencing the IANA
registry for OAuth Token Endpoint Authentication Methods for
available client authentication methods.
As described in [research.ust], the attacker can then utilize the
obtained client authentication assertion to impersonate the client
and, for example, obtain access tokens.
2.1.1.2. Endpoints Requiring Client Authentication
As mentioned above, the attack is only possible if the client
authenticates to an endpoint other than the token endpoint at A-AS.
This is because if the client sends a token request to A-AS, it will
use A-AS' token endpoint as published by A-AS and hence, send the
token request to H-AS, i.e., the attacker cannot obtain the client
assertion.
Würtele, et al. Expires 19 December 2025 [Page 5]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
As detailed in [research.ust], the attack is confirmed to be possible
if the client authenticates with such client assertions at the
following endpoints of A-AS:
* Pushed Authorization Endpoint (see [RFC9126])
* Token Revocation Endpoint (see [RFC7009])
* CIBA Backchannel Authentication Endpoint (see [OpenID.CIBA])
* Device Authorization Endpoint (see [RFC8628])
Note that this list of examples is not exhaustive. Hence, any client
that might authenticate at any endpoint other than the token endpoint
SHOULD employ countermeasures as described in Section 2.1.2.
2.1.1.3. Affected Client Authentication Methods
The same attacks are possible for the private_key_jwt client
authentication method defined in [OpenID.Core], as well as
instantiations of client authentication assertions defined in
[RFC7521], including the SAML assertions defined in [RFC7522].
Furthermore, a similar attack is possible for jwt-bearer
authorization grants as defined in Section 2.1 of [RFC7523], albeit
under additional assumptions (see [research.ust] for details).
2.1.2. Countermeasures
At its core, audience injection attacks exploit the fact that, from
the client's point of view, an authorization server's token endpoint
is a mostly opaque value and does not uniquely identify an
authorization server. Therefore, an attacker authorization server
may claim any URI as its token endpoint, including, for example, an
honest authorization server's issuer identifier. Hence, as long as a
client uses the token endpoint as an audience value when
authenticating to the attacker authorization server, audience
injection attacks are possible. Therefore, audience injection
attacks need to be prevented by the client.
Note that the following countermeasures mandate the use of single
audience value (as opposed to multiple audiences in array). This is
because Section 4.1.3 of [RFC7519] allows the receiver of an
audience-restricted JWT to accept the JWT even if the receiver
identifies with only one of the values in such an array.
Würtele, et al. Expires 19 December 2025 [Page 6]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
Clients that interact with more than one authorization server and
authenticate with signature-based client authentication methods MUST
employ one of the following countermeasures, unless audience
injection attacks are mitigated by other means, such as using fresh
key material for each authorization server.
Note that the countermeasures described in Section 2.1.2.1 and
Section 2.1.2.2 do not imply any normative changes to the
authorization server: Section 4.1.3 of [RFC7519] requires the
authorization server to only accept a JWT if the authorization server
can identify itself with (at least one of the elements in) the JWT's
audience value. Authentication JWTs produced by a client
implementing one of these countermeasures meet this condition. Of
course, an authorization server MAY still decide to only accept its
issuer identifier (Section 2.1.2.1) or the endpoint that received the
JWT (Section 2.1.2.2) as an audience value, for example, to force its
clients to adopt the respective countermeasure.
2.1.2.1. Authorization Server Issuer Identifier
Clients MUST use the authorization server's issuer identifier as
defined in [RFC8414]/[OpenID.Discovery] as the sole audience value in
client assertions. Clients MUST retrieve and validate this value as
described in Section 3.3 of [RFC8414]/Section 4.3 of
[OpenID.Discovery].
For jwt-bearer client assertions as defined by [RFC7523], this
mechanism is also described in [OAUTH-7523bis].
Note that "issuer identifier" here does not refer to the term
"issuer" as defined in Section 4.4 of [RFC9700], but to the issuer
identifier defined in [RFC8414] and [OpenID.Discovery]. In
particular, the issuer identifier is not just "an abstract identifier
for the combination the authorization endpoint and token endpoint".
2.1.2.2. Exact Target Endpoint URI
Clients MUST use the exact endpoint URI to which a client assertion
is sent as that client assertion's sole audience value.
This countermeasure can be used for authorization servers that do not
use authorization server metadata [RFC8414] or OpenID Discovery
[OpenID.Discovery].
Würtele, et al. Expires 19 December 2025 [Page 7]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
2.2. Updates to Mix-Up Attacks
Mix-up attacks can occur 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 section extends the mix-up attack analysis in Section 4.4 of
[RFC9700]. It introduces additional attack variants that can occur
when clients use distinct redirection URIs for each authorization
server and clarifies the applicability of countermeasures to certain
attack variants.
2.2.1. Updates to "Per-AS Redirect URIs" Mix-Up Variant
The basic mix-up attack described in the initial paragraphs of
Section 4.4.1 of [RFC9700] specifies, as one of its preconditions,
that "the client stores the authorization server chosen by the user
in a session bound to the user's browser and uses the same
redirection URI for each authorization server".
If the client instead uses a distinct redirection URI for each
authorization server (i.e., Per-AS Redirect URIs), three subvariants
of mix-up attacks are still possible. This section updates the
description of the "Per-AS Redirect URIs" mix-up variant in
Section 4.4.1 of [RFC9700], with subvariants 1 and 2 newly introduced
in this document:
Per-AS Redirect URIs: There are three subvariants of mix-up attacks
when the client uses distinct redirection URIs for each authorization
server.
Subvariant 1: Advanced Mix-up Attack. If the client uses different
redirection URIs for different authorization servers but treats them
as the same URI, a slight variant of the basic mix-up attack remains
possible (see Footnote 7 of [arXiv.1601.01229]). In this attack, the
attacker not only replaces the client ID as in the basic mix-up
attack, but also replaces the redirection URI when redirecting the
browser to the authorization endpoint of the honest authorization
server.
This advanced mix-up attack is described in detail below, with the
Preconditions as well as Step 2 and Step 3 updated compared to the
basic mix-up attack.
Preconditions: For this variant of the attack to work, it is assumed
that
Würtele, et al. Expires 19 December 2025 [Page 8]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
* 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
* the client stores the authorization server chosen by the user in a
session bound to the user's browser and uses distinct redirection
URIs for different authorization servers, but treats them as the
same URI (i.e., it does not use the redirection URI to
differentiate authorization servers at the redirection endpoint).
In the following, it is further assumed that the client is registered
with H-AS (URI: https://honest.as.example, client ID: 7ZGZldHQ) and
with A-AS (URI: https://attacker.example, client ID: 666RVZJTA).
Assume that the client issues the redirection URI
https://client.com/9XpLmK2qR/cb for H-AS and
https://client.com/4FvBn8TzY/cb for A-AS. URLs shown in the
following example are shortened for presentation to include only
parameters relevant to the attack.
Attack on the authorization code grant:
1. The user selects to start the grant using A-AS (e.g., by clicking
on a button on the client's website).
2. 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
https://attacker.example/
authorize?response_type=code&client_id=666RVZJTA
&redirect_uri=https%3A%2F%2Fclient.com%2F4FvBn8TzY%2Fcb.
3. 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, and replaces the redirection URI of A-AS
with the redirection URI of H-AS. Therefore, the browser
receives a redirection (303 See Other) with a Location header
pointing to https://honest.as.example/
authorize?response_type=code&client_id=7ZGZldHQ
&redirect_uri=https%3A%2F%2Fclient.com%2F9XpLmK2qR%2Fcb.
4. The user authorizes the client to access their resources at H-AS.
H-AS issues a code and sends it (via the browser) back to the
client.
5. Since the client still assumes that the code was issued by A-AS,
it will try to redeem the code at A-AS's token endpoint.
Würtele, et al. Expires 19 December 2025 [Page 9]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
6. 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 Section 4.5
of [RFC9700].
Subvariant 2: Naïve RP Session Integrity Attack. If clients use
different redirection URIs for different authorization servers, and
clients do not store the selected authorization server in the user's
session, attackers can mount an attack called "Naïve RP Session
Integrity Attack". Note that unlike other mix-up variants, the goal
of this attack is not to obtain an authorization code or access
token, but to force the client to use an attacker's authorization
code or access token for H-AS. See Section 3.4 of [arXiv.1601.01229]
for details.
Subvariant 3: Cross Social-Network Request Forgery. If clients use
different redirection 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 redirection URIs
properly (see Section 4.1 of [RFC9700]), attackers can mount an
attack called "Cross Social-Network Request Forgery". These attacks
have been observed in practice. Refer to [research.jcs_14] for
details.
2.2.2. Clarifications on Countermeasures for Mix-Up Variants
Section 4.4.2 of [RFC9700] specifies two countermeasures, Mix-Up
Defense via Issuer Identification and via Distinct Redirect URIs
(referred to hereafter as "existing mix-up defenses"). Both defenses
require the client to store and compare the issuer of the
authorization server. Specifically, the issuer is defined in the
second paragraph of Section 4.4.2 of [RFC9700] as follows:
The issuer serves ... 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 ..., a different unique identifier for this tuple or the
tuple itself can be used instead.
Existing mix-up defenses are sufficient to protect against most
attack variants, with a few specific cases requiring clarification:
* For the mix-up attack variant in "Implicit Grant", since the flow
does not involve a token endpoint, a unique identifier for the
authorization endpoint URL MAY be used as the equivalent of issuer
if an issuer identifier is not available. Then, clients MUST
apply existing mix-up defenses.
Würtele, et al. Expires 19 December 2025 [Page 10]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
* For all three subvariants of the "Per-AS Redirect URIs" attack
variant (Section 2.2.1), clients MUST follow existing mix-up
defenses to defend against mix-up attacks. Clients MAY choose to
reuse the per-AS redirection URI already configured in their
deployments to satisfy the "distinct redirection URI for each
issuer" requirement when implementing the "Mix-Up Defense via
Distinct Redirect URIs" defense (Section 4.4.2.2 of [RFC9700]).
For subvariant 3 ("Cross Social-Network Request Forgery"), the
existing mix-up defenses alone are not sufficient. In addition,
authorization servers MUST enforce exact redirection URI matching,
as specified in Section 4.1.3 of [RFC9700].
Note that when the issuer is not unique to a client (i.e., when a
client can interact with multiple configurations of the same
authorization server), the security considerations go beyond the
scope of mix-up attacks and are discussed further in Section 2.3.
2.3. Attacks in Open Ecosystems
This section describes the OAuth use case and associated attacks in
open ecosystems, along with practical countermeasures tailored to
such environments.
2.3.1. OAuth in Open Ecosystems
In traditional OAuth deployments, a client registers with an
authorization server to access protected resources hosted by a
resource server. The means through which the client registers with
an authorization server typically involve the client developer
manually registering the client at the authorization server's
website, or by using Dynamic Client Registration [RFC7591]. The
client may access different resources from distinct resource servers,
thereby requiring registration with multiple authorization servers.
The choice of what resources to access (and thus which authorization
and resource servers to integrate) is at the discretion of the client
(or client developer).
This section discusses OAuth in "open ecosystems", where the
protected resources accessible to a client are configured beyond the
discretion of the client or client developers. This can be the case,
for example, if the client offers an open marketplace or registry
where external developers can publish information about resource
servers and associated authorization servers at development time
(e.g., in integration platforms, where external services register
themselves as authorization and resource servers with a platform that
acts as a client, see [research.cuhk]), or if an end-user can specify
any compliant configurations to interact with at runtime (e.g., in
the Model Context Protocol [MCP-Spec]).
Würtele, et al. Expires 19 December 2025 [Page 11]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
This document defines a "client configuration" as a set of
configuration elements that enable a client to access an OAuth 2.0
protected resource, including details about the authorization server,
client registration, and the resource server. In open ecosystems,
these configuration elements are typically managed as follows:
* Authorization Server configuration: Clients may employ a manual
approach, where external developers or end-users enter the
necessary fields (i.e., endpoint URLs of the authorization server)
at the client's website, or support fetching information about the
authorization server via Authorization Server Metadata [RFC8414].
* Client Registration configuration at the authorization server:
Clients may employ a manual approach, where external developers or
end-users enter the necessary fields (i.e., client identifier and
client credentials) at the client's website, or support fetching
information about the client registration via Dynamic Client
Registration [RFC7591].
* Protected Resource configuration: Clients may employ a manual
approach, where external developers or end-users enter the
necessary fields (i.e., endpoint URLs of the resource server) at
the client's website, or support fetching information about the
protected resource via Protected Resource Metadata [RFC9728].
External developers or end-users may further specify when and how
the protected resources shall be fetched and processed by the
clients.
The integration pattern in open ecosystems expands the use of OAuth
in dynamic scenarios, creating new challenges with respect to
functionality and security beyond the scope of [RFC9700].
2.3.2. Attack Scenario
With the new integration model, OAuth in open ecosystems introduces
two notable implications:
* Increased risk of malicious integration: Since the responsibility
of integrating client configurations is shifted to external
developers or end-users, there is an increased risk that malicious
client configurations may be introduced, including attacker-
controlled authorization servers or resource servers.
* New requirements for handling shared issuers: Clients shall
support client configurations with potentially shared issuers
(explained below) to fulfill functional needs, which in turn
introduces new security gaps.
Würtele, et al. Expires 19 December 2025 [Page 12]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
In traditional OAuth deployments, it is implicitly assumed that there
is exactly one client configuration for each client-authorization
server pair. Under this assumption, the issuer (as defined in
Section 4.4.2 of [RFC9700]) serves as a unique identifier for the
client. This has led to the common practice of clients tracking "the
authorization server chosen by the user" during OAuth flows, as well
as the adoption of existing mix-up defenses (Section 4.4.2 of
[RFC9700]), all of which are based on the issuer concept that
uniquely identifies each authorization server from the client's point
of view.
In open ecosystems, however, the new integration pattern does not,
and fundamentally cannot, restrict the use of the same authorization
server across multiple client configurations. For instance, clients
may legitimately integrate various functionalities that access
different resources or process the same resources differently, while
relying on the same authorization server (i.e., having shared
issuers, which implies that the issuer no longer uniquely identifies
a client configuration).
As a result, the client may integrate with an authorization server
under the attacker's control (Section 2.3.3), or an attacker-
controlled resource server paired with an honest authorization server
-- even if the authorization server is already integrated at the
client under a different client configuration (Section 2.3.4).
2.3.3. Mix-Up Attacks Reloaded
This section provides a tailored attack description and alternative
countermeasure for mix-up attacks in open ecosystems. The
descriptions here follow [research.cuhk], where additional details
are laid out.
2.3.3.1. Attack Description
Section 4.4 of [RFC9700] exemplifies scenarios in which an attacker-
controlled authorization server may be introduced:
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.
OAuth deployments in open ecosystems extend the above scenarios: an
external developer or end-user can introduce an attacker-controlled
authorization server by integrating a new client configuration at the
client.
Würtele, et al. Expires 19 December 2025 [Page 13]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
Furthermore, multiple client configurations may use the same
authorization server (i.e., share the same issuer). To manage such
scenarios, the client should treat each client configuration
independently, typically by keeping track of the client configuration
chosen by the user during the OAuth flow. For example, the client
may store a unique identifier for each client configuration (rather
than for each authorization server) in the user's session, or assign
a distinct redirection URI to each client configuration. This
enables the client to distinguish between client configurations,
retrieve the correct client registration information for access token
requests, and access the intended protected resources.
Attackers can exploit this setup to mount mix-up attacks, using a
malicious authorization server from an attacker-controlled client
configuration to target the honest authorization server from an
honest client configuration. For details on this attack vector, see
"Cross-app OAuth Account Takeover" (COAT) and "Cross-app OAuth
Request Forgery" (CORF) in Section 4.2 of [research.cuhk].
As an example, the attack analogous to the Advanced Mix-up Attack
described in Section 2.2.1 is outlined below.
Preconditions: For this variant of the attack to work, it is assumed
that
* the implicit or authorization code grant is used with multiple
client configurations of which one is considered "honest"
(H-Config) and one is operated by the attacker (A-Config), and
* the client stores the client configuration chosen by the user in a
session bound to the user's browser and uses distinct redirection
URIs for different client configurations, but treats them as the
same URI (i.e., it does not use the redirection URI to
differentiate client configurations at the redirection endpoint).
In the following, it is further assumed that the client is registered
with an honest authorization server H-AS (URI:
https://honest.as.example, client ID: 7ZGZldHQ) under H-Config and
with an attacker-controlled authorization server A-AS (URI:
https://attacker.example, client ID: 666RVZJTA) under A-Config.
Assume that the client issues the redirection URI
https://client.com/9XpLmK2qR/cb for H-Config and
https://client.com/4FvBn8TzY/cb for A-Config. URLs shown in the
following example are shortened for presentation to include only
parameters relevant to the attack.
Attack on the authorization code grant:
Würtele, et al. Expires 19 December 2025 [Page 14]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
1. The user selects to start the grant using A-Config (e.g., by
clicking on a button on the client's website).
2. The client stores in the user's session that the user selected
"A-Config" and redirects the user to A-AS's authorization
endpoint with a Location header containing the URL
https://attacker.example/
authorize?response_type=code&client_id=666RVZJTA
&redirect_uri=https%3A%2F%2Fclient.com%2F4FvBn8TzY%2Fcb.
3. 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-Config
with the client's ID at H-Config, and replaces the redirection
URI of A-Config with the redirection URI of H-Config. Therefore,
the browser receives a redirection (303 See Other) with a
Location header pointing to https://honest.as.example/
authorize?response_type=code&client_id=7ZGZldHQ
&redirect_uri=https%3A%2F%2Fclient.com%2F9XpLmK2qR%2Fcb.
4. The user authorizes the client to access their resources at H-AS.
H-AS issues a code and sends it (via the browser) back to the
client.
5. Since the client assumes that the code was issued in the
interaction with A-Config, it will try to redeem the code at
A-AS's token endpoint.
6. 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 Section 4.5
of [RFC9700].
2.3.3.2. Countermeasures
At its core, a client in open ecosystems may integrate multiple
configurations of the same authorization server, and therefore the
issuer may not be unique to the client. While the existing mix-up
defenses in Section 4.4.2 of [RFC9700] are sufficient, a variant of
the "Mix-Up Defense via Distinct Redirect URIs" defense described in
Section 4.4.2.2 of [RFC9700] MAY be deployed instead for practical
reasons:
To apply this defense, clients MUST use a distinct redirection URI
for each client configuration they interact with. Clients MUST
check that the authorization response was received from the
correct client configuration by comparing the distinct redirection
Würtele, et al. Expires 19 December 2025 [Page 15]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
URI for the client configuration to the URI where the
authorization response was received on. If there is a mismatch,
the client MUST abort the flow.
To maximize compatibility, this countermeasure imposes no new
requirements on authorization servers compliant with the original
OAuth 2.0 specification [RFC6749]. This is essential for securing
open ecosystems where clients may be integrated with numerous client
configurations, and many authorization servers may not support the
"Mix-Up Defense via Issuer Identification" defense described in
Section 4.4.2.1 of [RFC9700] (e.g., returning the issuer identifier
via an iss parameter in the authorization response [RFC9207]).
To ease the development burden, compared to the "Mix-Up Defense via
Distinct Redirect URIs" defense outlined in Section 4.4.2.2 of
[RFC9700], this countermeasure does not require clients to manage
issuers exclusively for mix-up defense. Instead, it relies on
existing isolation boundaries that already serve the functional need
of differentiating client configurations.
Note that this countermeasure is not intended to redefine the concept
of an issuer (or issuer identifier) from an authorization server-
specific identifier to one tied to client configurations. Nor does
it invalidate the existing countermeasures described in Section 4.4.2
of [RFC9700] and clarified in Section 2.2.2, which remain sufficient
to mitigate mix-up attacks in open ecosystems. Rather, this
countermeasure MAY serve as an alternative defense.
2.3.4. Client Configuration Confusion Attack
When client authentication is not required such as in the implicit
grant or for a public client, or when signature-based client
authentication methods such as private_key_jwt (as defined in
[OpenID.Core]) or signed JWTs (as defined in [RFC7521] and [RFC7523])
are used, a malicious resource server may be able to obtain an access
token issued by an honest authorization server. This is achieved by
registering an honest authorization server at the client under a
malicious client configuration, pairing it with an attacker-
controlled resource server, thus tricking the client into sending its
access tokens to the attacker instead of using them at the honest
resource server.
Unlike mix-up attacks or audience injection attacks, client
configuration confusion attacks do not involve a malicious
authorization server, but rather an honest one used in a malicious
client configuration.
Würtele, et al. Expires 19 December 2025 [Page 16]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
2.3.4.1. Attack Description
Client configuration confusion attacks are feasible if a client
satisfies the following preconditions:
1. The client has at least two client configurations, one of which
is configured by an attacker. The client allows for the two
configurations to use the same authorization server (i.e.,
issuer-sharing client configurations) but different resource
servers.
2. The client stores the client configuration chosen by the user in
a session bound to the user's browser and assigns the same
redirection URI for at least the issuer-sharing, if not all,
client configurations.
3. The client uses the same client ID across the issuer-sharing
client configurations.
4. Regarding client authentication, one of the following applies:
* The client authenticates to the authorization server in both
client configurations with a signature-based authentication method
(e.g., the jwt-bearer client authentication from [RFC7523]) using
the same key pair.
* The client interacts with the authorization server in both client
configurations without requiring client authentication (i.e.,
using the implicit grant, or as a public client).
For brevity of presentation, in the following, let H-AS, H-RS, and
H-Config denote an honest authorization server, resource server, and
client configuration, respectively. Let A-AS, A-RS, and A-Config
denote an attacker-controlled authorization server, resource server,
and client configuration, respectively.
2.3.4.1.1. Core Attack Steps
In the following, it is further assumed that the client is registered
with H-AS for both client configurations. The client is configured
to use A-RS for A-Config and H-RS for H-Config.
Attack on the authorization code grant:
1. The user selects to start the grant using A-Config (e.g., by
clicking on a button on the client's website).
Würtele, et al. Expires 19 December 2025 [Page 17]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
2. The client stores in the user's session that the user selected
"A-Config" and redirects the user to H-AS's authorization
endpoint.
3. The user authorizes the client to access their resources at H-AS.
Having validated that the client ID and redirection URI match the
ones assigned for H-Config, H-AS issues a code and sends it (via
the browser) back to the client.
4. The client redeems the code issued by H-AS at H-AS's token
endpoint. To authenticate with H-AS, the client creates a client
assertion signed by itself. Recall that both A-Config and
H-Config registered the client with H-AS under the same client
ID, and that the client uses the same key pair for authentication
at H-AS. Hence, this client assertion, if required, would be a
valid authentication credential for the client at H-AS. Note
that generating and validating client assertions in this step is
irrelevant for public clients.
5. Since the client stores "A-Config" in the user's session, it
sends the access token to A-RS. The attacker therefore obtains
the user's access token issued by H-AS.
Variant in Implicit Grant: In the implicit grant, H-AS issues an
access token instead of the code in Step 3. Step 4 is omitted. The
rest of the attack proceeds as above.
2.3.4.1.2. Discussion: on Sharing Client IDs
The scope of client configuration confusion attack is limited to the
reuse of registered clients, and considers phishing threats involving
the open registration of new clients as out of scope, because such
threats can be mitigated by existing mechanisms such as vetting
during manual registration, or via initial access tokens as defined
in Section 1.2 of [RFC7591].
For the attack to work, A-Config and H-Config need to share the same
client ID in client registration (precondition 3 in Section 2.3.4.1).
This can be the case, for example, if an external developer or end-
user can control the client ID used in A-Config during manual
registration, or if the client uses dynamic registration to get
assigned the same client ID for A-Config as in H-Config, as detailed
below.
When the client is designed to perform dynamic client registration
once per client configuration, A-Config and H-Config could feasibly
share the same client ID. Unlike the situation in Section 2.1, since
A-Config uses H-AS instead of A-AS, the attacker cannot directly
Würtele, et al. Expires 19 December 2025 [Page 18]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
control which client ID the authorization server assigns to A-Config.
However, according to the description of client ID returned in Client
Information Response (Section 3.2.1 of [RFC7591]):
client_id OAuth 2.0 client identifier string. It SHOULD NOT be
currently valid for any other registered client, though an
authorization server MAY issue the same client identifier to
multiple instances of a registered client at its discretion.
The second half of the last sentence explicitly allows a client to
obtain a client ID of the same value across multiple client
registrations, as long as the client is considered to be instances of
the same registered client by the authorization server.
This behavior is intended for registering different "client
instances", i.e., different deployed instances of the same piece of
client software (see Section 1.2 of [RFC7591]). However, the
authorization server cannot distinguish between this case and a
client registering multiple times for different client
configurations.
Specifically, when the client initiates dynamic registration at H-AS
based on H-Config and A-Config respectively, the authorization
server, recognizing the two client registration requests as
originating from the same client (e.g., indicated by the identical
software identifier or software statement provided by the client, see
Section 2 of [RFC7591] for their definitions), is likely to return
the same client ID according to Appendix A.4.2 of [RFC7591]:
Particular authorization servers might choose, for instance, to
maintain a mapping between software statement values and client
identifier values, and return the same client identifier value for
all registration requests for a particular piece of software.
Therefore, a client interacting with H-Config and A-Config could
feasibly share the same client ID when dynamic client registration is
used.
2.3.4.2. Countermeasures
At its core, client configuration confusion attacks exploit the fact
that, an attacker-controlled client configuration can reuse the
registered client at the honest authorization server under an honest
client configuration.
Clients in open ecosystems that interact with more than one client
configuration and support authorization servers that either use
signature-based client authentication methods or do not require
Würtele, et al. Expires 19 December 2025 [Page 19]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
client authentication MUST employ the following countermeasure,
unless client configuration confusion attacks are mitigated by other
means, such as using fresh key material for each authorization server
employing signature-based client authentication and disallowing any
authorization server that does not require client authentication.
Clients MUST issue a distinct redirection URI for each client
configuration they interact with, both during client registration and
in OAuth flows. This ensures that the redirection URI for the
attacker-controlled client configuration will fail the exact
redirection URI match (required by Section 4.1.3 of [RFC9700]) at the
honest authorization server, since the redirection URI at the honest
client configuration is the only redirection URI registered for the
client identifier at the honest authorization server.
When dynamic client registration is supported, clients SHOULD also
specify a different software identifier (software_id) in client
registration requests for each client configuration. This prevents
client registration requests from being rejected by the authorization
server when different redirection URIs are used, if the authorization
server follows the excerpt from Section 5 of [RFC7591] below:
An authorization server could also refuse registration requests
from a known software identifier that is requesting different
redirection URIs or a different client URI.
This countermeasure can be considered an actionable approach to
mitigating the "Counterfeit Resource Server" threat (see "Access
Token Phishing by Counterfeit Resource Server" in Section 4.9.1 of
[RFC9700]) within the context of open ecosystems. It is
complementary to general defenses for access token misuses, such as
sender-constrained and audience-restricted access tokens as specified
in Section 4.10 of [RFC9700].
3. Security Considerations
Security considerations are described in Section 2.
4. IANA Considerations
This document has no IANA actions.
5. References
5.1. Normative References
Würtele, et al. Expires 19 December 2025 [Page 20]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
"Assertion Framework for OAuth 2.0 Client Authentication
and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521,
May 2015, <https://www.rfc-editor.org/rfc/rfc7521>.
[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
2015, <https://www.rfc-editor.org/rfc/rfc7523>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/rfc/rfc8414>.
[RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
"Best Current Practice for OAuth 2.0 Security", BCP 240,
RFC 9700, DOI 10.17487/RFC9700, January 2025,
<https://www.rfc-editor.org/rfc/rfc9700>.
5.2. Informative References
[arXiv.1601.01229]
Fett, D., Küsters, R., and G. Schmitz, "A Comprehensive
Formal Security Analysis of OAuth 2.0", arXiv:1601.01229,
January 2016, <https://arxiv.org/abs/1601.01229/>.
[MCP-Spec] Anthropic, "Model Context Protocol (MCP) Specification",
March 2025, <https://modelcontextprotocol.io/
specification/2025-03-26>.
[OAUTH-7523bis]
Jones, M. B., Campbell, B., and C. Mortimore, "JSON Web
Token (JWT) Profile for OAuth 2.0 Client Authentication
and Authorization Grants", Work in Progress, Internet-
Würtele, et al. Expires 19 December 2025 [Page 21]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
Draft, draft-ietf-oauth-rfc7523bis-00, 21 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
rfc7523bis-00>.
[OpenID.CIBA]
Fernandez, G., Walter, F., Nennker, A., Tonge, D., and B.
Campbell, "OpenID Connect Client-Initiated Backchannel
Authentication Flow - Core 1.0", September 2021,
<https://openid.net/specs/openid-client-initiated-
backchannel-authentication-core-1_0.html>.
[OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 2", December 2023,
<https://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID.Discovery]
Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
Connect Discovery 1.0 incorporating errata set 2",
December 2023, <https://openid.net/specs/openid-connect-
discovery-1_0.html>.
[research.cuhk]
Luo, K., Wang, X., Fung, P. H. A., Lau, W. C., and J.
Lecomte, "Universal Cross-app Attacks: Exploiting and
Securing OAuth 2.0 in Integration Platforms", 34th USENIX
Security Symposium (USENIX Security 25), August 2025,
<https://www.usenix.org/system/files/conference/
usenixsecurity25/sec24winter-prepub-332-luo.pdf>.
[research.jcs_14]
Bansal, C., Bhargavan, K., Delignat-Lavaud, A., and S.
Maffeis, "Discovering concrete attacks on website
authorization by formal analysis", Journal of Computer
Security, vol. 22, no. 4, pp. 601-657, April 2014,
<https://www.doc.ic.ac.uk/~maffeis/papers/jcs14.pdf>.
[research.ust]
Hosseyni, P., Küsters, R., and T. Würtele, "Audience
Injection Attacks: A New Class of Attacks on Web-Based
Authorization and Authentication Standards", April 2025,
<https://eprint.iacr.org/2025/629>.
[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
August 2013, <https://www.rfc-editor.org/rfc/rfc7009>.
Würtele, et al. Expires 19 December 2025 [Page 22]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC7522] Campbell, B., Mortimore, C., and M. Jones, "Security
Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0
Client Authentication and Authorization Grants", RFC 7522,
DOI 10.17487/RFC7522, May 2015,
<https://www.rfc-editor.org/rfc/rfc7522>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://www.rfc-editor.org/rfc/rfc7591>.
[RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
"OAuth 2.0 Device Authorization Grant", RFC 8628,
DOI 10.17487/RFC8628, August 2019,
<https://www.rfc-editor.org/rfc/rfc8628>.
[RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
RFC 9126, DOI 10.17487/RFC9126, September 2021,
<https://www.rfc-editor.org/rfc/rfc9126>.
[RFC9207] Meyer zu Selhausen, K. and D. Fett, "OAuth 2.0
Authorization Server Issuer Identification", RFC 9207,
DOI 10.17487/RFC9207, March 2022,
<https://www.rfc-editor.org/rfc/rfc9207>.
[RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0
Protected Resource Metadata", RFC 9728,
DOI 10.17487/RFC9728, April 2025,
<https://www.rfc-editor.org/rfc/rfc9728>.
Acknowledgments
We would like to thank
// TODO add names, sort by last name.
//
// -- Tim W. Daniel Fett, Wing Cheong Lau, Julien Lecomte, Aaron
Parecki, Guido Schmitz, and Xianbo Wang
for their valuable feedback and contributions to this document.
Würtele, et al. Expires 19 December 2025 [Page 23]
Internet-Draft Updates to OAuth 2.0 Security BCP June 2025
Document History
[[ To be removed from the final specification ]]
-01
* Updated temporary title
* Added introductory paragraphs, replaced placeholders
* Clarified issuer does not uniquely identify client config
* Cleaned up acknowledgement list
-00
* Initial version
Authors' Addresses
Tim Würtele
University of Stuttgart
Germany
Email: tim.wuertele@sec.uni-stuttgart.de
Pedram Hosseyni
University of Stuttgart
Germany
Email: pedram.hosseyni@sec.uni-stuttgart.de
Kaixuan Luo
The Chinese University of Hong Kong
Hong Kong
Email: kaixuan@ie.cuhk.edu.hk
Adonis Fung
Samsung Research America
United States of America
Email: adonis.fung@samsung.com
Würtele, et al. Expires 19 December 2025 [Page 24]