MCP OAuth flaws expose a one-click account takeover path

At a glance

What this is: Obsidian Security shows that remote MCP servers can be turned into one-click account takeover paths when OAuth flows rely on shared client IDs, weak state binding, and loose redirect controls.

Why it matters: IAM and SaaS security teams need to treat MCP integration design as an access-governance problem, because a single broken consent flow can expose high-value third-party permissions and downstream SaaS data.

Context

Remote MCP servers sit between an AI client and the SaaS authorization server, which means they inherit the complexity of OAuth while also introducing their own trust decisions. In this article, that complexity becomes the security problem: consent, state, and redirect handling are being used as if they were stable identity controls, even though the MCP proxy pattern changes what those controls actually protect.

For identity teams, the issue is not just whether OAuth works. It is whether the MCP server preserves user-bound authorization semantics when it behaves as both an authorization server for the client and an OAuth client to the SaaS provider. Once those roles blur, account takeover can emerge from design assumptions rather than a single isolated coding mistake.

This is an application of NHI governance to AI-connected access paths. The vulnerable object is not a human login but a delegated integration channel that can inherit broad SaaS permissions and then redirect those permissions through a different client relationship.

Key questions

Q: What breaks when MCP OAuth consent is not bound to the user session?

A: The approval step stops proving who initiated the request and starts proving only that a browser reached the page. In proxy-based MCP flows, that gap lets an attacker reuse a valid authorization path, capture the code, and complete token exchange on a different endpoint. The practical risk is account takeover through consent replay.

Q: Why do shared MCP client IDs increase takeover risk?

A: Because the downstream authorization server sees one proxy identity instead of many distinct end users. Consent can be cached for the shared client_id, so a later malicious request may inherit prior approval without another prompt. That turns a convenience feature into a reusable authorization boundary that attackers can exploit.

Q: What signs show an MCP OAuth flow is too permissive?

A: Look for generic consent screens, dynamic redirect registration without strict allow lists, state values that are not tied to a browser session, and token exchange logic that relies on proxy-side mappings alone. Those signals indicate the flow can drift away from the user’s actual intent and become vulnerable to code interception or replay.

Q: How should teams decide whether MCP needs a dedicated OAuth governance review?

A: They should review any MCP deployment that proxies multiple clients through one static OAuth identity, because that is where consent caching, callback handling, and token exchange become coupled. If a single approval can authorize a broad SaaS integration path, the flow deserves the same scrutiny as a privileged access channel.

Technical breakdown

Why shared client IDs break OAuth consent boundaries

Remote MCP servers often sit in the middle of two OAuth relationships at once. They present themselves as an authorization server to the MCP client, while also acting as a single OAuth client to the downstream SaaS authorization server. That proxy design collapses multiple end users into one shared client_id, which means the downstream authorization server can no longer distinguish one MCP client from another. Consent caching then becomes dangerous, because the decision is remembered for the proxy identity rather than the actual user-facing session.

Practical implication: treat shared client_id designs as a consent boundary risk, not a convenience feature.

How state, session, and redirect_uri validation should line up

OAuth state exists to bind an authorization response to the request that started it, but that protection only works when the state value is tied to a real user session and the redirect target is constrained. In the flawed MCP flow, an attacker can get an authorization code redirected to an attacker-controlled endpoint because the server does not tightly bind the OAuth state to the same browser session that approved consent. If redirect_uri handling is weak, the code becomes transferable across users and requests.

Practical implication: enforce state-session binding and strict redirect_uri registration for every dynamic client path.

Why proxy architectures create a larger attack surface than direct OAuth

A direct OAuth client has a clearer relationship with the authorization server and fewer opportunities to split trust across layers. The MCP proxy pattern introduces two consent surfaces, two code exchanges, and often two token objects, which increases the number of places where an implementation can drift from the intended security model. The result is not just one bug but a repeatable class of failures, including CSRF-style abuse, consent replay, and code interception through malicious links or injected browser state.

Practical implication: simplify MCP authorization paths where possible and remove unnecessary proxy-mediated trust decisions.

Threat narrative

Attacker objective: The attacker wants to obtain usable OAuth tokens and perform MCP tool actions as the victim inside the connected SaaS environment.

1. Entry occurs when the victim clicks a crafted authorization link that drives the MCP OAuth flow through a malicious redirect path.
2. Credential access occurs when the attacker captures the OAuth authorization code issued for the shared MCP client_id.
3. Escalation occurs when the attacker exchanges the code for tokens and uses the victim’s granted permissions through the MCP server.
4. Impact occurs when the attacker invokes MCP tools against the downstream SaaS account and accesses victim data or functions.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Gitloker GitHub extortion campaign: Phishing via GitHub notifications tricked developers into authorising malicious OAuth apps; Gitloker then wiped repos and demanded contact.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shared-client OAuth proxying creates an identity boundary that no longer maps to the user. When an MCP server acts as both an OAuth client and an authorization server, the downstream provider sees only one client identity, not the actual human or session behind it. That means consent and reuse decisions are being made at the wrong layer. The practitioner conclusion is that delegated integration identities need their own governance model, not just reused OAuth plumbing.

Consent is only meaningful when it is bound to the session that expressed it. The article shows that once state, browser session, and redirect target drift apart, the approval step stops proving user intent and starts proving only that some browser reached a page. That is a control failure, not a user-experience issue. The practitioner conclusion is that MCP authorization flows must be evaluated as a trust-chain problem, not as a login feature.

One-click takeover is a governance failure because it turns prior authorization into reusable standing access. The same approval that seemed harmless in the initial session can be replayed through a different client path if the proxy model preserves consent too broadly. That makes the blast radius of a single OAuth mistake much larger than the visible request path. The practitioner conclusion is that teams should review where consent is being cached across identities and sessions.

MCP authentication design needs to be read through OWASP-NHI and API security together. The vulnerable pattern combines over-trusted non-human access paths with API-facing redirect logic and token exchange behaviour. That is why the problem sits at the intersection of NHI governance, OAuth federation, and application-layer access control. The practitioner conclusion is that AI-connected SaaS access should be governed as a machine-mediated identity surface, not a normal app integration.

Redirect validation is now an identity control, not just a web security control. In proxy-based MCP deployments, the redirect_uri determines whether a code can be stolen, replayed, or delivered to the wrong party. That means a seemingly narrow implementation choice can determine whether account takeover is possible at all. The practitioner conclusion is that teams should classify redirect governance as part of access governance.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
• Read next: MCP Security Guide

What this signals

Consent replay is the core failure mode: when a single proxy client_id stands in for many end users, the authorization server cannot tell whether a later request is the same user or a different client borrowing prior approval. That makes consent caching an identity problem, not just an OAuth usability choice.

The operational signal to watch is any MCP deployment that treats redirect handling and token exchange as routine plumbing. Once those steps can be influenced by attacker-controlled browser state, the integration is no longer behaving like a simple connector; it is behaving like a delegated access broker with takeover potential.

For practitioners

• Tighten OAuth state-session binding Bind every authorization state value to the browser session that initiated consent, and reject callbacks that do not match that original session context.
• Restrict redirect_uri registration Allow only pre-approved redirect targets for MCP clients, and deny dynamic registration paths that permit attacker-controlled callback destinations.
• Expose full consent context Show client identity, requested scope, and destination clearly in MCP consent prompts so users can distinguish the legitimate client from a malicious one.
• Audit shared-client proxy patterns Inventory MCP servers that reuse one static OAuth client identity across multiple downstream clients, then classify where consent caching could cross session boundaries.
• Treat code exchange as a privileged boundary Review token exchange and callback handling as privileged operations, because a leaked authorization code is enough to complete takeover when the proxy path is weak.

Key takeaways

• Remote MCP OAuth flows can fail when shared client identities, session binding, and redirect validation are treated as implementation details instead of access controls.
• The article shows that a single malicious click can be enough to capture an authorization code and reuse granted SaaS permissions through the MCP server.
• Teams should review MCP deployments for consent replay risk, strict redirect allow lists, and browser-session binding at the authorization boundary.

Key terms

• Remote MCP Server: A Remote MCP server exposes tools over a network so an AI client can discover and invoke them through a standard protocol. In security terms, it becomes part of the identity chain, because it brokers requests, handles authorization, and can expand the blast radius when its OAuth implementation is weak.
• OAuth Consent: The approval that allows an application to access resources on behalf of a user or tenant. In practice, consent can create durable access paths that outlive the original interaction if permissions are broad, unmanaged, or never reviewed. For security teams, it is both an access decision and a lifecycle event.
• Authorization Code Interception: An attack where a malicious process steals the authorization code before the intended client can redeem it. The threat is strongest in public clients and redirect environments that can be observed or hijacked. PKCE is the control designed to prevent the stolen code from being useful.
• State-Session Binding: State-session binding links an OAuth state value to the browser session that began the login or consent request. This prevents cross-site request forgery style abuse by ensuring that the callback can only succeed in the same session context that created it.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.