Updates to OAuth 2.0 Security Best Current Practice

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).¶

"issuer": "https://honest.com",
"token_endpoint": "https://honest.com/token",
...

"issuer": "https://attacker.com",
"token_endpoint": "https://honest.com/token",
...

"iss": "cid",
"sub": "cid",
"aud": "https://honest.com/token"

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

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.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 NOT share OAuth providers with completed client registrations across toolkits and tenants belonging to different owners.¶

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.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] and [research.cuhk3].¶

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]).¶