Internet-Draft Updates to OAuth 2.0 Security BCP June 2026
Würtele, et al. Expires 26 December 2026 [Page]
Workgroup:
Web Authorization Protocol
Internet-Draft:
draft-ietf-oauth-security-topics-update-02
bcp:
240
Updates:
6749, 6750, 7521, 7522, 7523, 9700 (if approved)
Published:
Intended Status:
Best Current Practice
Expires:
Authors:
T. Würtele
University of Stuttgart
P. Hosseyni
University of Stuttgart
K. Luo
The Chinese University of Hong Kong
A. Fung
Samsung Research America

Updates to OAuth 2.0 Security Best Current Practice

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-ietf-oauth-security-topics-update.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics-update/.

Discussion of this document takes place on the Web Authorization Protocol Working Group 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/.

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 26 December 2026.

▲

Table of Contents

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.

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.4 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.3).

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",
...

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 (see Section 2.1.1.2). 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.

Once the attacker obtained such a client assertion, it can impersonate the client towards H-AS. This enables multiple attacks. For example, the attacker may obtain access tokens via a client credentials grant. Another example is the attacker initiating a regular authorization code grant where a victim user grants access to the honest client at H-AS, but the access token ends up with the attacker (since the attacker fully impersonates the client in this case, mechanisms like DPoP [RFC9449] cannot protect against the attack).

Further attack scenarios and additional details are given in [research.ust].

2.1.1.2. Token Endpoint as Client Assertion Audience

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.

2.1.1.3. 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.

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.4. 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.

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. It is RECOMMENDED to prefer the countermeasure described in Section 2.1.2.1.

The countermeasures described below mandate the use of single audience value (as opposed to multiple audiences in an 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. Since the countermeasures rely on the client using an unambiguous audience value, there is no value in including additional ones (that would need to be unambiguous as well).

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 of 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].

2.1.2.3. Implementation Considerations

Technically, 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 (client assertion) JWT if the authorization server can identify itself with (at least one of the elements in) the JWT's audience value. Client assertions produced by a client implementing one of these countermeasures meet this condition.

However, some existing authorization server implementations only accept their token endpoint as the audience value in client assertions, including for authentication at endpoints other than the token endpoint. Clients interacting with such authorization servers MUST employ alternative countermeasures. In this case, clients SHOULD use one of the following countermeasures, in decreasing order of preference:

  1. Use distinct authentication key material with each authorization server.

  2. Ensure the use of unique client identifiers across all authorization servers (note that this might not be feasible in some ecosystems, for example, in connection with OpenID Federation [OpenID.Federation]).

  3. Ensure uniqueness of all (client identifier, token endpoint) pairs and use the token endpoint as the sole audience value in all client assertions.

While an authorization server that already accepts (among other values) its issuer identifier or the exact endpoint as client assertion audience values does not need to change anything, such an authorization server MAY still decide to restrict acceptance to its issuer identifier (Section 2.1.2.1) or the endpoint that received the client assertion (Section 2.1.2.2) as an audience value, for example, to force its clients to adopt the respective countermeasure.

2.2. Cross-toolkit OAuth Account Takeover

It is increasingly common and observed that a single OAuth client supports multiple tools. Each set of tools, known as a toolkit, is mapped to an OAuth provider configuration, which includes at least the authorization server (AS) endpoints and client registration. A successful OAuth connection is established when the OAuth client obtains an access token for a tool based on its corresponding OAuth provider configuration. The tool can then use the access token to access the user's protected resource at a resource server (RS).

Multiple OAuth connections can be linked to some form of user identity based on the following common deployment scenarios:

  • Application Integration: The OAuth connections made with different toolkits are linked to an application's user account or session (e.g., represented by an application's user identifier or a short-lived anonymous session). This is common where a user authorizes an application (e.g., a cloud platform or an agentic AI service) to orchestrate multiple tools, some of which together with their OAuth providers can be contributed by the public.

  • Multi-tenant OAuth-as-a-Service (also known as Token Vault): In cases where OAuth responsibilities of a client are managed by a multi-tenant OAuth-as-a-Service provider, a successful OAuth connection is linked to a tenant's user identifier in addition to the tenant identifier. This is a generalization of the last deployment scenario, where an application using this OAuth-as-a-Service is becoming a tenant. A tenant can usually choose some off-the-shelf toolkits using (partially-) completed OAuth providers, if not adding their own toolkits with custom OAuth providers to support the tenant's service.

When controlled by an attacker, the open configurations of OAuth providers have posed a new threat to this centralized OAuth client design. If the client fails to properly identify, track, and isolate which proper OAuth connection context (representing a combination of OAuth provider, toolkit, and tenant) is in use during an authorization flow, an attacker can exploit this to mount Cross-toolkit OAuth Account Takeover (COAT) attacks (see [research.cuhk] and [research.cuhk2]). The COAT attacker uses a malicious toolkit to steal a victim's authorization code issued by an honest OAuth provider of an honest toolkit, and applies the authorization code injection (as defined in Section 4.5 of [RFC9700]) against a new OAuth connection with the attacker's identity. This results in a compromised OAuth connection between the attacker's application identity and the victim's toolkit access. The impact is equivalent to an account takeover: the attacker can operate the honest toolkit with the victim's account (hijacked either under the same application, or even cross-tenant that shares a vulnerable OAuth-as-a-service).

2.2.1. Attack Description

Preconditions: It is assumed that

  • the implicit or authorization code grant is used with multiple OAuth connection contexts, of which one is considered "honest" (H-Toolkit using H-AuthProvider with H-AS) and one is operated by the attacker (A-Toolkit using A-AuthProvider with A-AS), and

  • the client stores the connection context chosen by the user in a session bound to the user's browser, and

  • the authorization servers properly check the redirection URI by enforcing exact redirection URI matching (otherwise, see Cross Social-Network Request Forgery in [research.jcs_14] for details).

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/honest-cb for the honest toolkit and https://client.com/attack-cb for the attacker-controlled toolkit. 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. A victim user selects to start the grant using A-AS of A-Toolkit (e.g., by initiating a tool use on an agentic AI service).

  2. The client stores in the user's session that the user has selected this OAuth connection context 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&state=[state] &redirect_uri=https%3A%2F%2Fclient.com%2Fattack-cb.

  3. When the user's browser navigates to the A-AS, the attacker immediately redirects the browser to the authorization endpoint of H-AS. In the authorization request, the attacker uses the honest authorization URL and replaces the state with the one freshly received. Therefore, the browser receives a redirection with a Location header pointing to https://honest.as.example/authorize?response_type=code&client_id=7ZGZldHQ&state=[state] &redirect_uri=https%3A%2F%2Fclient.com%2Fhonest-cb.

  4. Due to implicit or prior approvals, the user might not be prompted for a re-authorization (re-consent). H-AS issues a code and sends it (via the browser) back with the state to the client.

  5. Since the client still assumes that the code was issued by A-Toolkit, as stored in the user's session (with state verified), 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].

This Cross-toolkit OAuth Account Takeover (COAT) attack is a generalization of the Cross-app OAuth Account Takeover as defined in [research.cuhk] and the mix-up attack as defined in Section 4.4 of [RFC9700]. This COAT exploits confusion between the OAuth connection context (i.e., a combination of OAuth provider, toolkit, tenant) of a centralized client rather than being limited to confusion between two distinct authorization servers.

Variants:

  • COAT under the OAuth-as-a-Service context: the attack above can be launched with a malicious tenant by adding a custom toolkit with an OAuth provider that targets an honest AS used by another tenant's toolkit. A variation of this attack involves the malicious tenant simply using a shared off-the-shelf toolkit that comes with a pre-built OAuth provider (with client registration included), if so allowed.

  • Implicit Grant: In the implicit grant, the attacker receives an access token instead of the code in Step 4. The attacker's authorization server receives the access token when the client makes either a request to the A-AS userinfo endpoint (defined in [OpenID.Core]) or a request to the attacker's resource server (since the client believes it has completed the flow with A-AS).

  • Cross-toolkit OAuth Request Forgery (CORF): If clients do not store the selected OAuth connection context in the user's session, but in the redirection URI instead, attackers can mount an attack called Cross-toolkit OAuth Request Forgery (CORF). This results in a compromised OAuth connection between the victim's application identity and the attacker's toolkit access. The goal of this specific attack variant 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. This Cross-toolkit OAuth Request Forgery attack is a generalization of the Cross-app OAuth Request Forgery as defined in [research.cuhk] and the Naïve RP Session Integrity Attack when the OAuth connection context is limited to AS, and is detailed in Section 3.4 of [arXiv.1601.01229].

  • OpenID Connect: Some variants can be used to attack OpenID Connect. In these attacks, the attacker misuses features of the OpenID Connect Discovery [OpenID.Discovery] mechanism or replays access tokens or ID Tokens to conduct a mix-up attack. The attacks are described in detail in Appendix A of [arXiv.1704.08539] and Section 6 of [arXiv.1508.04324v2] ("Malicious Endpoints Attacks").

2.2.2. Countermeasures

The client MUST use all variables in its supported OAuth connection context to form a connection context identifier that uniquely identifies each AS instance configured at the client. This identifier always includes the unique toolkit identifier. Additionally,

  • a client allowing each toolkit to use multiple OAuth providers, of which one AS may be compromised as assumed in Section 4.4 of [RFC9700], MUST also include the OAuth provider identifier;

  • a multi-tenant client MUST also include the tenant identifier, if the toolkit identifier is not globally unique.

Unless otherwise specified as follows, the client MUST issue per-context distinct redirection URI that incorporates this unique connection context identifier. When initiating an authorization request, the client MUST store this identifier in the user's session. When an authorization response was received on the redirection endpoint, the client MUST also check that the context identifier from the distinct redirection URI matches with the one in the user's session. If there is a mismatch, the client MUST abort the flow.

Existing countermeasures for mix-up attacks (Section 4.4 of [RFC9700]) can be a replacement under the following conditions:

  • the client has entirely dropped the support to implicit grant, and

  • the OAuth provider specifies an AS not by individually configured AS endpoints but instead by an abstract issuer identifier (as defined in Section 4.4.2 of [RFC9700]) that represents the endpoints, and

  • the issuer identifier is used either in place of the connection context identifier in the redirection URI or is separately returned according to [RFC9207], and

  • an additional runtime resolution is used to resolve the issuer to retrieve the associated AS endpoints (e.g., with the authorization server metadata [RFC8414] or OpenID Discovery [OpenID.Discovery]). Clients using such resolution solely to pre-populate individual AS endpoint fields, without any coupling with the issuer identifier will remain vulnerable.

2.3. Cross-user OAuth Session Fixation

Based on similar deployment needs as outlined in Section 2.2, multiple OAuth connections can be linked to some form of user's identity (e.g., an application's user identifier). This identity information is supposedly maintained in a session established and already bound to the user agent. In real-world deployments, however, this prerequisite can be broken for various reasons. For instance, in OAuth deployments that cross user agents, where an authenticated native app has its backend acting as a confidential OAuth client, the client opens a tool linking URL in an external user agent (typically a browser, as defined in [RFC8252]) that has no authenticated sessions with the client. As a workaround, the client introduces a session fixation vulnerability: it encodes a session identifier into the URL, which fixates a dedicated authorization session to complete the OAuth flow with the user at the client.

The Cross-user OAuth Session Fixation exploits this session fixation attack vector. The attacker attempts to trick a victim into completing an OAuth flow that the attacker has initiated at the client. As a result, the attacker's session will be used to establish an OAuth connection with the victim's tool resources or identity, hence resulting in the same impact as COAT (Section 2.2). However, this attack exploits confusion over the intended user bound to that connection context during the OAuth flow, contrasting with COAT, which exploits confusion within the OAuth connection context (OAuth provider, toolkit, tenant).

In general, this session fixation vulnerability may be viewed as violating the requirement of "binding the contents of state to the browser (more precisely, the initiating user agent) session" to defend against Cross-Site Request Forgery (CSRF, see Section 4.7 of [RFC9700]). However, while PKCE [RFC7636] can mitigate CSRF, PKCE alone cannot mitigate this new attack: Since the entire OAuth flow including the authorization request and the request to redirection endpoint is completed by the same victim user, the cryptographic binding of authorization request and access token request enforced by PKCE is preserved. The impact of the new attack is also more severe than that of typical CSRF attacks.

Note that this section focuses on the authorization code grant. For similar attacks in cross-device OAuth flows, see Section 4 of [CDFS].

2.3.1. Attack Description

Preconditions: It is assumed that the client has maintained a user's session. But it does not want to or cannot authenticate the user at the redirection endpoint for usability reasons, before completing the OAuth flow.

Example Attack:

  1. From a vulnerable client, the attacker initiates OAuth against a tool and obtains an authorization request URL, in which the state parameter has encoded a newly created authorization session of the attacker.

  2. The attacker sends this authorization request URL to a victim.

  3. The victim visits the URL and (automatically, due to prior or implicit approvals,) authorizes the client to access their resources.

  4. Upon receiving the state at the redirection endpoint, the client fixates the attacker's authorization session and completes the OAuth flow.

  5. The attacker's account at the client now gains access to the victim's resources.

Variant:

The client may first generate a pre-authorization URL for the purpose of fixating a session before redirecting to the authorization endpoint.

Non-normative example request:

GET /oauth?auth_session_id=6064f11c-f73e-425b-b9b9-4a36088cdb2b HTTP/1.1
Host: client.com

Non-normative example response:

HTTP/1.1 303 See Other
Location: https://as.example/authorize?
          response_type=code&client_id=K9dTpWzqL7&state=b1d8f043
          &redirect_uri=https%3A%2F%2Fclient.com%2Fcb
Set-Cookie: auth_session_id=6064f11c-f73e-425b-b9b9-4a36088cdb2b

This variant differs from the above only by obtaining and sending the pre-authorization URL instead, which will first fixate the attacker's authorization session (rather than in Step 4).

2.3.2. Countermeasures

To defend against the Cross-user OAuth Session Fixation attack, the client MUST ensure that an OAuth flow initiated by one user is completed by the same user.

The most straightforward countermeasure is to identify the initiating user via their existing session at the client, rather than introducing a fixated session, if usability conditions permit. However, eliminating the session fixation vector may not always be feasible due to application needs. For instance, when the OAuth client responsibilities of establishing OAuth connections and the application's session management are handled by separate entities (e.g., separate services isolated under different origins, accessed from different user agents, or when the OAuth client is outsourced to an OAuth-as-a-Service provider), as observed in practice by [research.cuhk2].

Hence, the client MUST validate the binding of any newly fixated authorization session (conveyed via state or the pre-authorization URL) to the existing user session (maintained at the user agent) that initiates the OAuth flow, before proceeding with the access token request. Depending on the specific current settings:

  • If the user session is accessible at the redirection endpoint, the client can validate this binding directly.

  • If the user session is not accessible at the redirection endpoint, for example, because the redirection endpoint is hosted in a different origin or accessed from a different user agent than where the user session is maintained, the countermeasure requires one of the following to make the session accessible prior to validation:

    • an implementation change to co-locate the redirection endpoint under the same origin as the endpoint maintaining the user session, and/or to re-authenticate the user at the redirection endpoint from the external user agent (e.g., a browser), or

    • from the current redirection endpoint, performing a further redirection back to the starting origin and/or user agent where the existing session is available. For native apps, the redirect options specified in Section 7 of [RFC8252] MUST be used. The location of this further redirection MUST NOT be controllable by an attacker, or it will result in Open Redirection (Section 4.11 of [RFC9700]).

2.4. Shared Consent in Brokered OAuth

In a brokered OAuth deployment, an intermediate entity (called the broker in the following) mediates between downstream clients and one or more upstream authorization servers (referred to as AS in the following). The broker acts as an OAuth client towards each AS. Towards its downstream clients, the broker either acts as an authorization server itself, exposing a standards-compliant OAuth interface, or it exposes a custom, non-OAuth interface.

The attack and countermeasures described in this section apply regardless of which of these two interfaces the broker exposes to its downstream clients.

Throughout this section, the terms upstream and downstream are used relative to the broker and the direction in which authorization flows. The AS is upstream as the source of authorization and tokens, while the clients the broker serves are downstream as the recipients of the access the broker obtains on their behalf.

The term downstream client furthermore denotes a unit of trust rather than necessarily a single application or an OAuth client in the sense of [RFC6749]. Multiple applications under common administrative control, such as the applications of a single tenant of a multi-tenant broker or the applications of an organization operating its own broker, may legitimately share a single registration and consent decision and thus be treated as a single downstream client. Applications under separate administrative control constitute distinct downstream clients.

When the broker registers itself once at an AS and reuses this single registration for every downstream client it serves, the AS cannot distinguish between those downstream clients. As a consequence, the consent the user grants for one downstream client is silently reused for any other downstream client that integrates the same broker. A malicious downstream client integrated with the same broker can therefore obtain access to the user's protected resources without the user ever consenting to that client.

2.4.1. Attack Description

The descriptions here follow [research.rub], where additional details of the attack are laid out. Shared consent attacks require at least two downstream clients (one honest, one malicious) to be integrated with the same (honest) broker, and that broker to register itself as a client at the (honest) upstream AS.

In the following, let H-Client and M-Client be downstream clients (honest and attacker-controlled, respectively) integrated with broker B. As a non-normative example, the description assumes that B exposes a standards-compliant OAuth interface to its downstream clients.

The broker B registers itself once at the AS and obtains a client identifier cid_B@AS together with a redirection URI bound to the broker. The broker uses this registration whenever it issues an authorization request triggered from any of its downstream clients to the AS. At B, H-Client is registered as cid_HC@B and M-Client is registered as cid_MC@B, each with its own redirection URI bound to the respective downstream client. From the point of view of the AS, every flow that B initiates appears to come from the same client cid_B@AS, regardless of which downstream client actually triggered the flow.

The broker acts invisibly to the user during the flow. It renders no consent screen of its own and no other user-visible UI that would indicate that an additional entity is involved between the downstream client and the AS.

The exact form of the authorization response (authz res) returned to a downstream client is out of scope for this attack.

The flaw is illustrated in the following figure:

  User        H-Client      M-Client          B                      AS
    |============================ Phase 1 ============================|
    |             |    authz req: cid_HC@B    |                       |
    |             |-------------------------->|                       |
    |             |             |             |  authz req: cid_B@AS  |
    |             |             |             |---------------------->|
    |             |          consent: cid_B@AS|                       |
    |<--------------------------------------------------------------->|
    |             |             |             |       authz res       |
    |             |             |             |<----------------------|
    |             |         authz res         |                       |
    |             |<--------------------------|                       |
    |============================ Phase 2 ============================|
    |             |           authz req: cid_MC@B                     |
    |             |             |------------>|                       |
    |             |             |             |  authz req: cid_B@AS  |
    |             |             |             |---------------------->|
    |             |             |             |       authz res       |
    |             |             |             |<----------------------|
    |             |             |  authz res  |                       |
    |             |             |<------------|                       |

In the second phase of the figure, no consent prompt is rendered for M-Client. The AS only sees the broker's client identifier cid_B@AS, for which the user has already granted consent in the first phase, so the AS silently issues a token to B (cf. prompt=none, as defined in Section 3.1.2.1 of [OpenID.Core]) and B returns an authz res to M-Client.

2.4.2. Countermeasures

The root cause of shared consent attacks is that the AS cannot tell on whose behalf the broker is acting and therefore cannot ask the user for consent on a per-downstream-client basis. Brokers MUST employ at least one of the following two countermeasures.

2.4.2.1. Per-Client Registration at the Upstream Authorization Server

Each downstream client MUST be registered as a separate client at the AS. When initiating an authorization flow to the AS on behalf of a downstream client, the broker MUST use the registration of exactly that downstream client.

The specific mechanism by which these per-client registrations are established is out of scope of this document. In practice, they are commonly established as follows: The broker provides each downstream client with a redirection URI that is hosted by the broker, and instructs the downstream client to register at every AS it expects to use, using the broker-provided redirection URI. The downstream client performs this registration at each AS, obtaining a distinct client identifier (e.g., cid_HC@AS for H-Client and cid_MC@AS for M-Client) and any associated credentials (such as a client secret). The downstream client then hands these credentials over to the broker, which gives the broker full control to act on behalf of the downstream client at the AS.

This countermeasure ensures that the AS recognizes each downstream client as a distinct client, and that any consent prompt rendered by the AS is bound to a single downstream client. Consent granted for one downstream client is therefore not reusable for another.

  User        H-Client      M-Client          B                      AS
    |             |             |             |                       |
    |             |    authz req: cid_HC@B    |                       |
    |             |-------------------------->|                       |
    |             |             |             | authz req: cid_HC@AS  |
    |             |             |             |---------------------->|
    |             |         consent: cid_HC@AS|                       |
    |<--------------------------------------------------------------->|
    |             |             |             |       authz res       |
    |             |             |             |<----------------------|
    |             |         authz res         |                       |
    |             |<--------------------------|                       |
    |             |             |             |                       |
    |             |           authz req: cid_MC@B                     |
    |             |             |------------>|                       |
    |             |             |             | authz req: cid_MC@AS  |
    |             |             |             |---------------------->|
    |             |         consent: cid_MC@AS|                       |
    |<--------------------------------------------------------------->|
    |             |             |             |       authz res       |
    |             |             |             |<----------------------|
    |             |             |  authz res  |                       |
    |             |             |<------------|                       |

Unless consent for the downstream client has already been granted, the broker MUST present an explicit consent screen to the user that identifies the downstream client, before initiating its own authorization request to the AS on behalf of the downstream client. The broker MUST NOT skip this consent screen based on a previously granted consent for a different downstream client. The broker MAY remember the user's consent decision per downstream client (e.g., per client_id of the downstream client), but MUST NOT remember it across different downstream clients.

This countermeasure prevents the broker from silently reusing a consent granted for one downstream client when initiating a request to the AS on behalf of another downstream client, even when the AS cannot distinguish between the broker's downstream clients.

  User        H-Client      M-Client          B                      AS
    |             |             |             |                       |
    |             |    authz req: cid_HC@B    |                       |
    |             |-------------------------->|                       |
    |            consent: cid_HC@B            |                       |
    |<--------------------------------------->|                       |
    |             |             |             |  authz req: cid_B@AS  |
    |             |             |             |---------------------->|
    |             |          consent: cid_B@AS|                       |
    |<--------------------------------------------------------------->|
    |             |             |             |       authz res       |
    |             |             |             |<----------------------|
    |             |         authz res         |                       |
    |             |<--------------------------|                       |
    |             |             |             |                       |
    |             |           authz req: cid_MC@B                     |
    |             |             |------------>|                       |
    |            consent: cid_MC@B            |                       |
    |<--------------------------------------->|                       |
    |             |             |             |  authz req: cid_B@AS  |
    |             |             |             |---------------------->|
    |             |             |             |       authz res       |
    |             |             |             |<----------------------|
    |             |             |  authz res  |                       |
    |             |             |<------------|                       |
2.4.2.3. Discussion of the Countermeasures

The two countermeasures have different practical trade-offs.

The Per-Client Registration countermeasure (Section 2.4.2.1) confronts the user with at most one consent screen per authorization flow, which improves the user experience. However, it requires each downstream client to be registered at every AS the broker integrates with, which can be a substantial effort given that a single broker is typically integrated with many ASes.

The Broker-Side Consent Screen countermeasure (Section 2.4.2.2) spares downstream clients this registration effort, since the broker's single registration at each AS is reused for all downstream clients. However, the user may be confronted with up to two consent screens in a single authorization flow: one rendered by the broker identifying the downstream client, and one rendered by the AS identifying the broker.

Both countermeasures are implemented entirely on the client side (the downstream client and the broker) and require no software or protocol changes to any AS.

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

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6749]
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8252]
Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", BCP 212, RFC 8252, DOI 10.17487/RFC8252, , <https://www.rfc-editor.org/rfc/rfc8252>.
[RFC8414]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, , <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, , <https://www.rfc-editor.org/rfc/rfc9700>.

5.2. Informative References

[arXiv.1508.04324v2]
Mladenov, V., Mainka, C., and J. Schwenk, "On the security of modern Single Sign-On Protocols: Second-Order Vulnerabilities in OpenID Connect", arXiv:1508.04324v2, , <https://arxiv.org/abs/1508.04324v2/>.
[arXiv.1601.01229]
Fett, D., Küsters, R., and G. Schmitz, "A Comprehensive Formal Security Analysis of OAuth 2.0", arXiv:1601.01229, , <https://arxiv.org/abs/1601.01229/>.
[arXiv.1704.08539]
Fett, D., Küsters, R., and G. Schmitz, "The Web SSO Standard OpenID Connect: In-Depth Formal Security Analysis and Security Guidelines", arXiv:1704.08539, , <https://arxiv.org/abs/1704.08539/>.
[CDFS]
Kasselman, P., Fett, D., and F. Skokan, "Cross-Device Flows: Security Best Current Practice", Work in Progress, Internet-Draft, draft-ietf-oauth-cross-device-security-15, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-cross-device-security-15>.
[OAUTH-7523bis]
Jones, M. B., Campbell, B., Mortimore, C., and F. Skokan, "Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and Assertion-Based Authorization Grants", Work in Progress, Internet-Draft, draft-ietf-oauth-rfc7523bis-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rfc7523bis-05>.
[OpenID.CIBA]
Fernandez, G., Walter, F., Nennker, A., Tonge, D., and B. Campbell, "OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0", , <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", , <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", , <https://openid.net/specs/openid-connect-discovery-1_0.html>.
[OpenID.Federation]
Hedberg, R., Jones, M., Solberg, A., Bradley, J., De Marco, G., and V. Dzhuvinov, "OpenID Federation 1.0", , <https://openid.net/specs/openid-federation-1_0-final.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), , <https://www.usenix.org/system/files/usenixsecurity25-luo-kaixuan.pdf>.
[research.cuhk2]
Luo, K., Wang, X., Fung, P. H. A., and W. C. Lau, "Demystifying the (In)Security of OAuth-based Account Linking in Connector Ecosystems", 2026 IEEE Symposium on Security and Privacy (SP), , <https://doi.ieeecomputersociety.org/10.1109/SP63933.2026.00128>.
[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, , <https://www.doc.ic.ac.uk/~maffeis/papers/jcs14.pdf>.
[research.rub]
Innocenti, T., Jannett, L., Mainka, C., Mladenov, V., and E. Kirda, ""Only as Strong as the Weakest Link": On the Security of Brokered Single Sign-On on the Web", , <https://ieeexplore.ieee.org/document/11023371>.
[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", , <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, , <https://www.rfc-editor.org/rfc/rfc7009>.
[RFC7519]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <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, , <https://www.rfc-editor.org/rfc/rfc7522>.
[RFC7636]
Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, , <https://www.rfc-editor.org/rfc/rfc7636>.
[RFC8628]
Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 Device Authorization Grant", RFC 8628, DOI 10.17487/RFC8628, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc9207>.
[RFC9449]
Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, , <https://www.rfc-editor.org/rfc/rfc9449>.

Acknowledgments

We would like to thank TODO add names, sort by last name.Tim W. Daniel Fett, Louis Jannett, Wing Cheong Lau, Julien Lecomte, Aaron Parecki, Guido Schmitz, and Xianbo Wang

for their valuable feedback and contributions to this document.

Document History

[[ To be removed from the final specification ]]

-02

-01

-00

Authors' Addresses

Tim Würtele
University of Stuttgart
Germany
Pedram Hosseyni
University of Stuttgart
Germany
Kaixuan Luo
The Chinese University of Hong Kong
Hong Kong,
China
Adonis Fung
Samsung Research America
United States of America