Skip to content

Demystifying the (In)Security of OAuth-based Account Linking
in Connector Ecosystems

This page provides the supplementary materials for our IEEE S&P 2026 paper, "Demystifying the (In)Security of OAuth-based Account Linking in Connector Ecosystems".

Abstract

Connector Ecosystem Overview

Modern productivity apps, automation platforms, and AI agents orchestrate across external tools through cloud-based "connectors". To obtain authorized access to connector accounts, these applications rely extensively on the OAuth 2.0 protocol. However, tracking authorization context across web origins and user-agents, while maintaining the binding to the applications' own user identities (i.e., a secure Account Linking process), pushes OAuth beyond its original client–server model assumptions. The rise of the OAuth-as-a-Service (OaaS) paradigm further complicates trust boundaries in OAuth.

In this paper, we present the first comprehensive study of OAuth-based account (mis)linking in connector ecosystems. By systematizing real-world account linking architectural patterns, we show how "OAuth connections", commonly introduced to manage account linking, can inadvertently break session integrity and security boundaries in OAuth. This enables multiple forms of connector account takeovers.

We develop OASIS (OAuth Session Integrity Scanner), an analysis framework that identifies account linking implementations and detects novel Cross-user OAuth session fixation (COSF) vulnerabilities in mobile apps. Our empirical analysis discovers 40 vendors susceptible to COSF and identifies additional Cross-tenant confused deputy threats in 8 OaaS providers. We propose practical countermeasures that have since been adopted by major vendors such as Amazon Bedrock AgentCore. We lead ongoing discussions and standardization efforts to update OAuth security best practices in the IETF.

Authors

Kaixuan Luo1, Xianbo Wang1, Pui Ho Adonis Fung2, Wing Cheong Lau1

1The Chinese University of Hong Kong; 2Samsung Research America

Paper

Download Paper (PDF)

Cite:

Kaixuan Luo, Xianbo Wang, Pui Ho Adonis Fung and Wing Cheong Lau, 
"Demystifying the (In)Security of OAuth-based Account Linking in Connector Ecosystems," 
in 2026 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 2026, pp. 2327-2346, 
doi: 10.1109/SP63933.2026.00128.

Slides

Download Slides (PDF)

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.

The following demos demonstrate attacks against Amazon Bedrock AgentCore (now fixed). Detailed vulnerability report: 1-Click Credential Provider Account Takeovers in Amazon Bedrock AgentCore.

Demo 1: Cross-user OAuth Session Fixation (COSF) on Amazon Bedrock AgentCore. The attacker initiates an OAuth flow with the target connector (e.g., Dropbox) via the agent application, fixating an OAuth session derived from their own app account in the victim's browser by sharing the resulting authorization URL as a crafted link. The victim's connector access is silently linked to the attacker's account, with no explicit consent required if prior authorization exists. Amazon resolved this by adopting the post-redirect pattern (D3), now documented in their developer guide and blog.

Demo 2: Cross-tenant COAT on Amazon Bedrock AgentCore. The attacker creates a malicious tenant with a custom connector whose authorization endpoint redirects to a benign connector (e.g., Dropbox). Since the Token Vault shares a single redirect_uri across all tenants and connectors, the victim's auth code for Dropbox is forwarded to the attacker's connector for code exchange. Amazon resolved this by assigning globally unique per-connector redirect_uris (by appending a UUID suffix to the original URI) and enforcing redirect_uri matching in OAuth flows, preventing cross-connector code theft enabled by a malicious tenant.

More PoC examples are available in this link.

Vulnerability Detection

OASIS (OAuth Session Integrity Scanner) is a static analysis framework that identifies account linking implementations and detects Cross-user OAuth Session Fixation (COSF) vulnerabilities in Android apps. Source code and experimental dataset are available at https://drive.google.com/drive/folders/1ic9RQCGezKVwuDxVokTQHDKBMo9CtygQ.

OASIS follows a two-phase exclusion-based approach:

PHASE I: Account Linking Identification

Filters Android apps from a large corpus (AndroZoo) that likely support OAuth-based account linking, progressively ruling out irrelevant apps:

  • Connector Icon–Name Co-location: Detects UIs with co-located connector brand names and logos.
  • Rule Out OAuth Public Clients: Excludes apps that invoke connector token endpoints on-device.
  • Exclude Local App Interactions: Removes apps using intents to launch locally installed connector apps.

PHASE II: COSF Vulnerability Detection

Analyzes how each app handles the OAuth callback:

  • Secure: App contains a class/module that parses both code and state parameters from the callback URI (but not id_token), indicating it processes OAuth callbacks locally, consistent with a robust defense.
  • Vulnerable: Otherwise, the OAuth callback is not handled in the native app, suggesting the cloud-side OAuth client relies solely on a fixated OAuth session for user identification.

Results: Among 27 Android apps with verified account linking, OASIS achieved 20 true positives, 4 true negatives, 3 false negatives, and 0 false positives.

FAQs

(Click to Expand)

FAQ1: How is COSF different from traditional OAuth (Login) CSRF?

Both attacks break OAuth session integrity, but in opposite directions:

  • OAuth Login CSRF: The attacker injects their own auth code into the victim's ongoing OAuth flow. The victim ends up completing the attacker's authorization, effectively logging into the attacker's account or accessing the attacker's resources.

  • COSF (Cross-user OAuth Session Fixation): The attacker fixates their own OAuth session (derived from their app account) in the victim's browser. The victim unknowingly completes an OAuth flow on behalf of the attacker, so the victim's connector access gets linked to the attacker's app account. The impact is reversed: the attacker gains access to the victim's resources.

FAQ2: How does COSF relate to classical web session fixation?

Both involve fixating a session identifier on a victim's device, but they differ in mechanism and defense.

Classical web session fixation (CWE-384) fixates an unauthenticated session ID before the victim logs in. Its well-established defense is session ID rotation upon login, now standard practice in web frameworks.

COSF fixates an OAuth session derived from an existing authenticated user session. Rotation does not help here, because the OAuth session is already tied to the attacker's authenticated identity; there is nothing to rotate away from. The correct defense is to verify the binding between the OAuth session and the app's user session at the OAuth callback, ensuring the user who initiated the flow is the same user who completes it.

FAQ3: Doesn't PKCE solve the problem?

No. PKCE does not mitigate COSF.

PKCE (RFC 7636) only preserves the binding between the authorization request and the token request. It does not verify the binding between the initiation of the OAuth flow and the authorization request.

In a COSF attack, both the authorization request and token request are completed within a single OAuth flow: the victim simply completes an OAuth flow that was initiated by the attacker. PKCE is satisfied end-to-end, yet the token is still associated with the attacker's app account.

FAQ4: Doesn't the OAuth state parameter protect against COSF?

Existing mechanisms like state parameter binding for OAuth CSRF protection are underspecified for ensuring end-to-end OAuth session integrity, especially when the user session is maintained on a different origin, user-agent, or trust domain.

RFC requirements mandate that the state parameter be bound to the user-agent (UA) session to defend against CSRF. Most developers implement this correctly.

However, vulnerabilities remain if the OAuth session itself is not securely bound to the app's user session. In cross-origin and cross-UA deployments, the OAuth callback is processed in an "unauthenticated space" separated from the original authenticated space. Even with state validated against the OAuth session (which identifies the app account receiving the token, and is itself a UA session), the OAuth session may still be fixatable, because it is accessible via URL parameters (e.g., ?sessionID=abc123 in a pre-authorization request), with the binding to the app's user identity not validated.

The correct defense is to ensure the OAuth callback is validated at the app's primary origin or native app where the user session exists.

FAQ5: How does Cross-tenant COAT differ from the original COAT attack?

The original COAT attack (USENIX Security '25) operates within a single-tenant integration platform with an open marketplace: a malicious connector embedded in the same platform exploits the OAuth client's failure to distinguish between connectors during the code exchange phase.

Cross-tenant COAT in OaaS relaxes the open marketplace requirement. Since any developer can create a tenant with custom connectors, a malicious agent in one tenant can steal auth codes intended for a benign connector in another tenant, even if the target tenant is a completely closed ecosystem. The root cause is the Token Vault's failure to verify that the connector completing OAuth is the same one that initiated it, and that both belong to the same tenant. Using a shared redirect_uri across tenants and connectors makes this check impossible (given the low adoption of RFC9207, and that all investigated Token Vaults manually provision OAuth providers instead of using RFC8414, and thus cannot provide a trusted ground-truth for the Authorization Server issuer identifier). The fix requires assigning a globally unique per-connector redirect_uri and enforcing its matching in OAuth flows.

FAQ6: How does OaaS with a Token Vault differ from Brokered SSO?

Both OaaS Token Vaults and SSO Brokers introduce a four-actor architecture into OAuth, but they differ fundamentally in how the flows are structured.

Brokered SSO (studied in IEEE S&P '25) chains two SSO flows side by side: one between the Broker and the Authorization Server (Broker↔AS), and another between the application and the Broker (App↔Broker). Each flow produces its own token — the Broker holds a token from the AS, and the app receives a corresponding token from the Broker for authenticating the app user. Importantly, that work focuses on Single Sign-On (SSO), where the security concern is which identity the user ends up logged in as.

OaaS with a Token Vault involves only a single OAuth flow and a single token. The Token Vault acts as the sole OAuth client, obtaining and holding the access token from the connector's Authorization Server. The application does not need to receive a separate OAuth token; instead, it presents a non-secret OAuth connection ID to the Token Vault to retrieve access tokens or trigger API calls on the user's behalf. This paper focuses on OAuth for authorization (delegated resource access / account linking), where the security concern is which app account this single access token ends up being associated with.

Proposed Changes to IETF

  • Published IETF Internet-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 the Internet-Draft.
    • We are also grateful to the OAuth community for the feedback and adoption as an OAuth Working-Group Draft.
  • Presented and discussed at IETF 125 meeting.
  • Collecting further feedback from the OAuth community ...

The draft covers: (1) the account linking / OAuth Connection scenario, (2) attack descriptions for COSF and COAT, and (3) proposed countermeasures including cross-origin/UA considerations for COSF and globally-unique identifier requirements for COAT.

Key Takeaways

  • New Attack Class: Cross-user OAuth Session Fixation (COSF): the first analysis of session fixation attacks in mainstream OAuth 2.0 deployments. One hyperlink click can compromise a user's connector access.

  • Systematic Framework: OAuth connections in connector ecosystems track <user, tenant, connector> authorization context. COSF breaks the user binding; Cross-tenant Client ID Confusion breaks tenant scoping; Cross-tenant COAT breaks connector distinction.

  • Industry-Wide Impact: 40 vendors (connector-equipped apps, integration platforms, and agentic AI infrastructures) are susceptible to COSF; 8 agentic AI infrastructures, acting as OaaS providers, additionally expose cross-tenant threats. Total $35,850 in bug bounties received.

  • Vulnerability Detection: Developed OASIS, a two-phase static analysis framework for detecting account linking implementations and COSF vulnerabilities in Android apps.

  • Community Impact: Countermeasures adopted by Amazon, Microsoft, Arcade.dev, and others. Actively working on updates to OAuth Security best practices at IETF.