OAuth Security Workshop (OSW) 2025

This page provides the supplementary material for our talk at OSW 2025, "Cross-app OAuth Attacks in Integration Platforms: Mix-up Attacks Reloaded". Details about the session can be found at the workshop's official website.

Abstract

OAuth Mix-up attacks were considered hard to exploit.

In this talk, we focus on open ecosystems like integration platforms that enable practical variants of mix-up attacks via malicious app integrations, and discuss potential tailored spec changes.

Description

Speaker: Kaixuan Luo

Co-authors: Xianbo Wang, Adonis Fung, Julien Lecomte, Wing Cheong Lau

In this talk, we will cover how the uses of OAuth 2.0 in emerging integration platforms have arisen severe new attacks and defenses that impact the majority of big Internet players and billions of their users. In general, the OAuth mix-up attacks [1] were considered of low real-world impact, and thus resulting in limited adoption of defenses [2,3]. This is because the attack assumes that an OAuth client interacts with multiple authorization servers (e.g., login with Google and Facebook), in which some of them is either malicious or compromised—something difficult to achieve in practice. However, this situation has shifted within integration platforms.

Integration platforms are cloud-based platforms that aggregate multiple third-party apps or services, providing users with unified control. Common types include Workflow Automation platforms, Virtual Voice Assistants, Smart Homes and Large Language Model (LLM) platforms with plugins support. For instance, users can configure the Microsoft Power Automate platform to automatically save their Gmail attachments to Dropbox.

These platforms employ OAuth 2.0-based Account Linking to connect end-users' app accounts to their platform account, enabling authorized API calls to app servers. This allows the platform to orchestrate a wide range of external services on behalf of end-users. As most integration platforms are open ecosystems that welcome any developers to integrate their apps in a marketplace, this openness leaves room for malicious apps (and thus malicious authorization servers) to infiltrate.

The first half of the talk will cover our work to appear in USENIX Security 2025 [4]. Within integration platforms, we identified new variants of mix-up attacks: Cross-app OAuth Account Takeover (COAT) and Request Forgery (CORF). As long as a victim user establishes account linking with a malicious app, or potentially with just a click on a crafted link, they risk unauthorized access or privacy leakage of any apps on the platform. The vulnerabilities are prevalent across 15+ mainstream vendors. For example, an attacker can compromise victims' Microsoft 365 suite or Azure services with their single click on an unassuming link (CVE-2023-36019 [5], CVSS: 9.6).

In the second half, we will highlight the changes needed from a specification perspective. We believe that OAuth specifications, such as the OAuth Security BCP, could be updated to include practical defenses tailored for integration platforms to address mix-up attacks. We will provide concrete recommendations to [3] for these updates.

Our preliminary study was presented in Black Hat USA 2024 [6].

References

[1] Daniel Fett, Ralf Küsters, and Guido Schmitz. 2016. A Comprehensive Formal Security Analysis of OAuth 2.0. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS '16). https://doi.org/10.1145/2976749.2978385

[2] https://datatracker.ietf.org/doc/html/rfc9207

[3] https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.4

[4] Kaixuan Luo, Xianbo Wang, Pui Ho Adonis Fung, Wing Cheong Lau, and Julien Lecomte. 2025. Universal Cross-app Attacks: Exploiting and Securing OAuth 2.0 in Integration Platforms. 34th USENIX Security Symposium (USENIX Security 25).

[5] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36019

[6] Kaixuan Luo, Xianbo Wang, Adonis Fung, Julien Lecomte, and Wing Cheong Lau. 2024. One Hack to Rule Them All: Pervasive Account Takeovers in Integration Platforms for Workflow Automation, Virtual Voice Assistant, IoT, & LLM Services. Black Hat USA 2024. https://www.blackhat.com/us-24/briefings/schedule/#one-hack-to-rule-them-all-pervasive-account-takeovers-in-integration-platforms-for-workflow-automation-virtual-voice-assistant-iot--llm-services-38994

Slide Deck

Full-text Proposed Changes to IETF

Next Steps: Revision to the OAuth Security BCP ([RFC9700])?

Research Paper

Note: The following paper PDF is only for internal preview at OAuth Security Workshop 2025 and IETF Meeting. The USENIX Association would be the first publisher of the work.

Cite:

Kaixuan Luo, Xianbo Wang, Pui Ho Adonis Fung, Wing Cheong Lau, and Julien Lecomte. 
Universal Cross-app Attacks: Exploiting and Securing OAuth 2.0 in Integration Platforms. 
To appear in 34th USENIX Security Symposium (USENIX Security 25), Seattle, WA, August 2025. USENIX Association.

Attack PoC

For a glimpse of the actual security impact, here's a quick demo of the attack we were able to launch on Microsoft Power Automate (CVE-2023-36019), such as stealing Outlook Emails in 1-Click:

FAQs

FAQ1: Isn't PKCE supposed to solve the problem?

The short answer is, No.

Indeed, PKCE is generally considered as effective in mitigating authorization code injection attacks, and can be an alternative defense to CSRF attacks in OAuth.

But as a malicious app, we can bypass PKCE. Not by exploiting implementation flaws like PKCE downgrade attacks, but invalidating the protection provided by PKCE at the spec level by following these concrete steps.

FAQ2: Isn't it just mix-up attacks?

Long story short, our Cross-app Attacks can be considered as practical variants of mix-up attacks.

• A brief review of history, initial discoveries of mix-up attacks can date back to 2015/16, where two groups of researchers first discovered that there could be such an attack in theory, and one of them is Daniel Fett. P.S. Special thanks to him for organizing this awesome event, and inviting us to submit to OSW.

• Over the years, there're also quite a few sessions at the OAuth Security Workshop on this topic, where people discuss whether mix-up attack is a real issue and how to mitigate this.

• The community discussion has led to two RFCs, one is an ad-hoc defense exclusively meant for mix-up attack [RFC9207], and the countermeasures are also discussed in the OAuth Security BCP [RFC9700], which has just been published in Jan 2025.

The idea of the mix-up attack is straightforward: The OAuth client could interact with multiple authorization servers, but stumbles upon one of them which is a malicious server. What the malicious server could do is to redirect the end-user to a benign server, where an authorization code would be issued. But the client still believes that it is interacting with the malicious authorization server, so it would forward the authorization code to the token endpoint of the malicious server. That's how an authorization code can be leaked to an attacker.

As a matter of fact, our research was original and conducted independently before we dig up all those literature for comparisons. But if you do compare the attack workflows, you can notice that our first Cross-app attack, the Cross-app OAuth Account Takeover (COAT) resembles the mix-up attack.

However, the difference lies in the application scenarios:

Usually, when people talk about mix-up attacks, people always use the traditional paradigm which we showed on the left-hand side. The most practical scenario where there are multiple authorization servers involved is SSO, because most websites support more than one IdPs.

But the thing is, the second precondition for the mix-up attack to work, is that there must be a malicious authorization server out there. This precondition is really hard to satisfy in practice, because you just cannot expect highly trusted entities like Google to be hacked, or a website like Spotify suddenly supports logging into an attacker-controlled IdP out of nowhere without prior trust. But if we look at the right-hand side, in integration platforms, since it is an open ecosystem, untrusted authorization servers could integrate a malicious app to get involved.

That's how mix-up attacks could turn from a theoretical attack to a practical attack, and that's why our subtitle is "Mix-up attack reloaded".

Speaking of suggested spec changes, the first one is about the "open ecosystem" setting.

Previously, the spec only mentions the circumstance where the attacker uses dynamic registration to register the client at a malicious Authorization Server, or if the server itself becomes compromised. Both are hard, just think about Spotify adding malicious.com for SSO, or the whole Sign in with Google feature gets hacked.

We added the scenario where the attacker proactively integrate and interact with the OAuth client through the openness of integration platforms. This reflects the paradigm shift of OAuth (w.r.t. registration direction).

BTW, remember that we have two attacks, one is COAT, the other is CORF. CORF or Cross-app OAuth Request Forgery is comparable to an attack that's not well-discussed in the community called Naïve RP session integrity attack, also initially proposed by Daniel Fett years ago.

This attack is also mixing up the authorization servers, and is like the symmetric side of COAT/mix-up attack, but it is NOT lumped under the umbrella of mix-up attacks. We also believe the spec could incorporate CORF, because we indeed found some instances of platforms susceptible to CORF.

FAQ3: Why can't we use existing mix-up defense?

The short answer is, they don’t automatically/magically fit in our use cases.

To further answer this question, first, let's dig up the 2 countermeasures described in the OAuth Security BCP:

• The first one is mix-up defense by issuer identification. The high-level idea is that, each authorization server would return a unique ID in the authorization response called issuer, or iss. That's a static ID that each authorization server could identify itself. The client would somehow also know what's the expected issuer is, and could ensure that this ground truth is trustworthy. This depends on some external mechanisms like OAuth authorization server metadata [RFC8414]. Then, at the redirection endpoint, the client could compare the returned issuer with its ground truth. This defense is further elaborated in RFC9207.

• The OAuth Security BCP also specifies an alternative defense. The idea is, the client would issue a distinct redirect_uri for each authorization server during OAuth registration, which serves as the ground truth. Because it is the client that generates this URI, it would be inherently trustworthy from the Client's perspective. And then, the client only needs to grab the returned redirect_uri, from the request URL to the redirection endpoint, and compare it with the ground truth.

Our claim is that, the second defense is the basis of the defense for Cross-app OAuth attacks, not the first one.

Why?

One reason is that for integration platforms, we're always talking about apps, not authorization servers. Even two apps could legitimately share the same authorization server, namely, using the same issuer identifier.

For example, there could be an official Dropbox app (see below), that supports upload and download files with these two APIs. But any 3rd-party developer could also publish a custom Dropbox app in the marketplace that perform some advanced operations, leveraging some other official APIs offered by Dropbox, such as download as a zip or export. So these two apps will share the same authorization server, but technically they handle OAuth independently, and they also have different API endpoints a.k.a. Resource Servers such that the tokens retrieved will be handled separately.

So to solve this mix-up problem in integration platforms, we need a unique per-app ID, that cannot be shared. But since issuer is a static authorization server ID that is not subject to change, it's hard to rely on this whole issuer concept for the app ID defense.

The other reason why the first defense wouldn't be ideal is that, we need trustworthy ground truth for issuer, but usually integration platform rely on manual registration, and does not support OAuth metadata. This raises a barrier for real-world adoptions:

Since issuers depend on the OAuth metadata to be trustworthy (which would host the metadata at a .well-known location and verify the domain ownership), and are returned as a new URL parameter in the authorization response, these deviate from the core spec RFC6749. The issuer defense would be the most useful when there're only a few Authorization Servers involved, operated by big-names that would be most willing to keep up with the latest specs.

But now we are talking about thousands of apps in integration platforms. It is impractical to expect each app to be compliant with the latest standards, but we want them to have the same level of security. So that's why we rely on the second defense, which shifts responsibility on the platform's OAuth client.

To summarize, we suggest the tailored spec changes for integration platforms to be built upon the second defense.

We highlight that both for functional and security needs of active app tracking, it should use a per-app identifier, such as an app ID, but not a per-authorization server identifier, such as the issuer.

Since the app ID is not returned as a new identifier in the authorization response, but relies on existing redirect_uri setup, it's more compliant with the original core OAuth spec. So that's why this is a practical defense that does not need special opt-ins by those numerous apps. Instead, having responsibility on the platform makes more sense, since it’s them opening up the vulnerability.

Moreover, it is a robust countermeasure that "kill two birds with one stone", mitigating CORF attacks as well.

For more information on our recommended defense, please refer to "Full-text Proposed Changes to IETF".

Key Takeaways

• As open ecosystems, Cross-app OAuth Attacks in Integration Platforms enable practical variants of Mix-up Attacks via malicious app integrations.
• Existing RFCs have AS-centric defense but lack app-centric defense. A per-app ID is the recommended isolation boundary for multi-app integrations.
• With 15+ vulnerable mainstream platforms identified and Hundreds/thousands of integrated apps per platform:
  • Pervasive Impact across the Internet;
  • Better rely on the platform (client) rather than individual apps (AS) for the defense.