Kaixuan Luo

Access delegation is indispensable for Agentic AI and Integration Platforms, where orchestration engines (e.g., Microsoft Power Automate, Copilot Studio) obtain access tokens from 3rd-party providers to act on behalf of end-users or authenticate end-users across chat channels. To better support these new use cases, there is a growing trend to offload token retrieval and lifecycle management to a separate cloud-based service (a.k.a. Credential Manager, Token Store), which enables developers to streamline "access re-delegation" when building AI agents and low-code solutions. Different home-grown variants of OAuth have emerged to support such access re-delegation architecture.
Unlike the traditional OAuth setup, re-delegation centralizes token handling via a dedicated OAuth Token Service (a.k.a. OAuth-as-a-Service), which introduces an abstract "OAuth connection". This connection provides an application a pre-configured handle for a managed OAuth token, outsourcing token negotiations with the OAuth Authorization Server to the Token Service. Unlike "Broker" architectures that chain together two OAuth flows (authorization server-broker and broker-application), under the new connection-based OAuth architecture, applications acquire and utilize tokens through proprietary "OAuth connections" instead.
We have found that such a proprietary approach often reintroduces critical new vulnerabilities previously mitigated by OAuth standards. In this talk, we explain how classic web vulnerabilities like Session Fixation, Open Redirect, Confused Deputy, XSS, and Cross-window Communication attacks have re-manifested themselves or been amplified within these proprietary, yet increasingly-common, connection-based OAuth architectures. Through practical exploits of these vulnerabilities, attackers can take over well-authenticated AI agents or gain unauthorized access to arbitrary integrations, all without explicit user consent.
Using Microsoft as a case study, we illustrate how connection-based OAuth architectures are adopted in Azure, Power Platform, and Copilot Studio. We systematize the attack surface and highlight how Microsoft’s case reflects the good, the bad and the ugly across the industry, revealing systemic issues shared by other vendors such as Composio and ByteDance Coze.
Attendees will walk away with an attacker’s mindset and actionable best practices in building a hardened auth layer for AI agents and integrations.

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.

Integration Platforms for Workflow Automation (e.g., Microsoft Power Automate), Virtual Voice Assistants (e.g., Amazon Alexa), Smart Homes (e.g., Google Home), and Large Language Model (LLM) platforms supporting Plugins (e.g. OpenAI ChatGPT), are becoming essential in our personal and professional lives. However, we find many of these platforms vulnerable to a new class of authorization attacks.
As one of their core functions, integration platforms support "Account Linking" to connect end-users’ accounts at third-party services/apps (e.g., Gmail, Dropbox) to their platform account. This enables the platform to utilize and orchestrate a wide range of external services on behalf of the end-user. For example, users can configure Microsoft Power Automate to automatically send an email whenever a new GitHub issue is filed. Multi-party authorizations are known to be error-prone and should have gone through strict security scrutiny. Yet, with our newly discovered attacks, we successfully exploit the account linking mechanisms of 24 out of 25 mainstream integration platforms, resulting in account takeovers or privacy leakage of integrated apps/services.
In this talk, we unveil how top-tier vendors improperly realize OAuth-based account linking under the new context of Integration Platforms. The failure to verify bindings with both the intended platform user and active third-party service/app compromises the session integrity of account linking. We detail the technical aspects of 3 attacks on integration platforms’ authorization frameworks: two enable account takeovers, and one leads to forced account linking of arbitrary services/apps. Notably, most attacks have easy-to-satisfy preconditions and can often be reduced to 1-click attacks. For instance, an attacker can compromise victims’ Microsoft 365 suite or Azure services with their single click on an unassuming link (a CVE with CVSS 9.6).
We also offer our comprehensive insights into best security practices and mitigations and highlight some vendors’ invalid remedial attempts for each identified threat, benefiting the wider community.