Updates to OAuth 2.0 Security Best Current Practice

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 are not listed here, except where clarifications or new recommendations are made.

Audience Injection Attacks When using signature-based client authentication methods such as private_key_jwt as defined in or signed JWTs as defined in and , 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.

Attack Description The descriptions here follow , 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 , see 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 ).

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 or 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: Excerpt from A-AS' metadata: 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:

Client registers at H-AS, and gets assigned a client ID cid.
Client registers at A-AS, and gets assigned the same client ID cid. Note that the client ID is not a secret ().

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: 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 , , , , , , and all standards referencing the IANA registry for OAuth Token Endpoint Authentication Methods for available client authentication methods. As described in , the attacker can then utilize the obtained client authentication assertion to impersonate the client and, for example, obtain access tokens.

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 , 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 )
Token Revocation Endpoint (see )
CIBA Backchannel Authentication Endpoint (see )
Device Authorization Endpoint (see )

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 .

Affected Client Authentication Methods The same attacks are possible for the private_key_jwt client authentication method defined in , as well as instantiations of client authentication assertions defined in , including the SAML assertions defined in . Furthermore, a similar attack is possible for jwt-bearer authorization grants as defined in , albeit under additional assumptions (see for details).

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 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 and do not imply any normative changes to the authorization server: 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 () or the endpoint that received the JWT () as an audience value, for example, to force its clients to adopt the respective countermeasure.

Authorization Server Issuer Identifier Clients MUST use the authorization server's issuer identifier as defined in / as the sole audience value in client assertions. Clients MUST retrieve and validate this value as described in /Section 4.3 of . For jwt-bearer client assertions as defined by , this mechanism is also described in . Note that "issuer identifier" here does not refer to the term "issuer" as defined in , but to the issuer identifier defined in and . In particular, the issuer identifier is not just "an abstract identifier for the combination the authorization endpoint and token endpoint".

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 or OpenID Discovery .

Cross-tool OAuth Account Takeover It is increasingly common and observed that a single OAuth client supports multiple tools, and each of which 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 resource at a resource server (RS). Multiple OAuth connections can be linked to some form of user's identity based on these common deployment scenarios:

Platform Integrations: The OAuth connections made with different tools are linked to a platform's user account or session (e.g., represented by a platform's user identifier or a short-lived anonymous session). This is common where a user authorizes a platform (e.g., agentic AI service) to orchestrate multiple tools, of which some of them together with their OAuth providers can be contributed by the public.
Multi-tenant OAuth-as-a-Service (OaaS): In cases when the OAuth client is 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 a platform using this OAuth-as-a-Service is becoming a tenant. A tenant can usually choose some off-the-shelf tools using (partially-)completed OAuth providers, if not adding their own 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, tool, and tenant) is in use during an authorization flow, an attacker can exploit this to mount the Cross-tool OAuth Account Takeover (COAT) attacks (see and ). The COAT attacker uses a malicious tool to steal a victim's authorization code issued by an honest OAuth provider of an honest tool, and apply the authorization code injection (as defined in ) against a new OAuth connection with the attacker's identity. This results in a compromised OAuth connection between the attacker's platform identity and the victim's tool account. The impact is equivalent to an account takeover: the attacker can operate the honest tool using the victim's tool account (hijacked either under the same platform, or even cross-tenant that shares a vulnerable OAuth-as-a-service).

Attack Description Preconditions: It is assumed that

the implicit or authorization code grant is used with multiple OAuth connection contexts, of which one combination is considered "honest" (H-Tool using H-AuthProvider with H-AS) and one is operated by the attacker (A-Tool 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 client issues redirection URIs which do not depend on all variables in the connection context (e.g., auth provider, tool, tenant), and
the authorization servers properly check the redirection URI by enforcing exact redirection URI matching (otherwise, see Cross Social-Network Request Forgery in 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 tool and https://client.com/attack-cb for the attacker's. URLs shown in the following example are shortened for presentation to include only parameters relevant to the attack. Attack on the authorization code grant:

A victim user selects to start the grant using A-AS of A-Tool (e.g., by initiating a tool use on an agentic AI service).
The client stores in the user's session that the user has selected such 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.
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.
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.
Since the client still assumes that the code was issued by A-Tool, as stored in the user's session (with state verified), it will try to redeem the code at A-AS's token endpoint.
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 .

This Cross-tool OAuth Account Takeover (COAT) attack is a generalization of the Cross-app OAuth Account Takeover as defined in and the mix-up attack as defined in . This COAT exploits confusion between the OAuth connection context (i.e., a combination of OAuth provider, tool, tenant) of a centralized client rather than limited to confusion between two distinct authorization servers. Variants:

COAT under the OaaS context: the attack above can be launched with a malicious tenant (1) simply using a shared off-the-shelf tool that comes with pre-built OAuth providers (with client registration included), if so allowed; or (2) adding a custom tool with an OAuth provider targeting an honest AS used by another tenant's tool.
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 ) or a request to the attacker's resource server (since the client believes it has completed the flow with A-AS).
Cross-tool 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-tool OAuth Request Forgery (CORF). This results in a compromised OAuth connection between the victim's platform identity and the attacker's tool account. 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-tool OAuth Request Forgery attack is a generalization of the Cross-app OAuth Request Forgery as defined in 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 .
OpenID Connect: Some variants can be used to attack OpenID Connect. In these attacks, the attacker misuses features of the OpenID Connect 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 and Section 6 of ("Malicious Endpoints Attacks").

Countermeasures The client MUST NOT share OAuth providers with completed client registrations across tools and tenants belonging to different owners. The client MUST use all variables in its supported OAuth connection context to form a unique connection context identifier, which always includes the unique tool identifier. Additionally,

a client allowing each tool to use multiple OAuth providers, of which one AS may get compromised as assumed in , MUST also include the OAuth provider identifier;
a cross-tenant client MUST also include the tenant identifier, if the tool 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 URI endpoint, clients MUST also check that the context identifier from the URI matches with the one in the distinct redirection URI. If there is a mismatch, the client MUST abort the flow. Existing mix-up countermeasures 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 individual AS endpoints but instead replaced with an abstract issuer identifier representing the endpoints, and
the issuer identifier is used either in place of the connection context identifier or is separately returned according to , and
an additional runtime resolution is used to resolve the issuer to retrieve the associated AS endpoints (e.g., with the authorization server metadata ). Clients using such resolution solely to populate an OAuth provider defined with individual AS endpoints and lack the connection context identifier defense will remain vulnerable.

Cross-user OAuth Session Fixation Based on similar deployment needs as outlined in , multiple OAuth connections can be linked to some form of user's identity (e.g., a platform'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 cross-user-agent OAuth deployments, where an authenticated native app with its backend acting as a confidential OAuth client, the client opens a tool linking URL in an external user agent (a browser) 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 connection 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 of COAT. 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, tool, 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 CSRF (). However, CSRF defenses, including PKCE , cannot mitigate this new attack, since the entire OAuth flow including the authorization request and the access token request are completed by the same victim user. The impact of the new attack is also more severe from that of typical CSRF attacks. Note that this section focuses on the authorization code grant. For similar attacks in cross-device OAuth flows, see .

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 connection. Example Attack:

From a vulnerable client, the attacker initiates OAuth against a tool and obtains an authorization request URL, in which the state has encoded a newly fixable authorization session of the attacker.
The attacker sends this authorization request URL to a victim.
The victim visits the URL and (automatically, due to prior or implicit approvals,) authorizes the client to access their resources.
Upon receiving the state at the redirection endpoint, the client fixates the attacker's authorization session and completes the OAuth connection.
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: Non-normative example response: This attack differs from the above only by obtaining and using the pre-authorization URL instead, which will first fixate the attacker's authorization session (rather than in Step 4).

Countermeasures Defending against the Cross-user OAuth Session Fixation attack requires ensuring that an OAuth connection flow initiated by one user MUST only be completed by the same user. The most straightforward countermeasure is to re-authenticate the user instead of trying to fixate a session if usability condition permits. It is also understandable that the session fixation vector cannot be eliminated due to application needs. For instance, the client's user session and the OAuth client responsible for making OAuth connections are handled by separate entities (e.g., separate services hosted and isolated under different origins, or when the OAuth client is outsourced to an OAuth-as-a-Service provider), as observed in practice by and . Hence, the client MUST bind any newly fixated session (conveyed via state or the preauthorization URL during an OAuth flow to establish the OAuth connection) with the existing session (maintained at the user agent) which initiates the OAuth flow, before proceeding with the access token request. Depending on the specific current settings:

When the endpoint with existing user session and the redirection endpoint are hosted in the same origin and same user agent, the client MUST validate the binding between the newly fixated session and the existing session before the access token request.
In case the redirection endpoint is hosted elsewhere (a different origin or user agent), the countermeasure requires:
- an implementation change to co-locate the endpoint with user session and the redirection endpoint in the same origin and user agent (see above), or
- at the current redirection endpoint, further redirect, using HTTP Location or native app redirection as detailed in , back to (the starting origin and/or user agent) where the existing session is available. The location of this further redirection MUST NOT be controllable by an attacker, or it will result in Open Redirection (). The client MUST validate the binding between the sessions before the access token request.