MCP OAuth flaws expose a one-click account takeover path

At a glance

What this is: This analysis shows how Remote MCP implementations that proxy OAuth can leak authorization codes and enable account takeover through weak consent and session binding.

Why it matters: IAM and NHI teams need to treat MCP servers as identity infrastructure, because a flawed OAuth proxy can turn an AI integration into a privilege escalation path.

👉 Read Obsidian Security's analysis of one-click account takeover in Remote MCP

Context

Model Context Protocol, or MCP, is becoming a common way for AI agents to reach SaaS tools and data, but the identity layer behind it is still being bolted onto existing OAuth patterns. That creates a governance gap for NHI teams, because the server may be acting as both a resource-facing integration layer and an OAuth intermediary without the controls normally expected of either role.

The operational issue is not just that an agent can call tools. It is that a shared OAuth client model, weak consent handling, and loose redirect controls can let one approval be reused in ways the original user never intended. For organisations building agentic access paths, this is typical of early MCP deployments rather than an edge case.

Key questions

Q: How should security teams govern MCP OAuth flows in enterprise environments?

A: Treat MCP OAuth as an identity control plane, not a convenience layer. Bind authorization state to the initiating session, display clear consent context, restrict redirect URIs, and review every proxy-style client registration. If the server cannot prove who initiated the request and where the callback should go, it should not issue a usable authorization code.

Q: Why do shared OAuth clients increase risk in Remote MCP deployments?

A: A shared OAuth client collapses many downstream users and tools into one upstream identity, which means consent decisions can be reused beyond their original context. That creates a larger attack surface for code leakage, redirect abuse, and unexpected token issuance. For practitioners, shared client_id designs require stronger session binding and stricter callback validation.

Q: What is the difference between token expiry and trust validation in MCP security?

A: Token expiry limits how long a credential can be used, but trust validation determines whether the credential should have been issued at all. In MCP, a short-lived code is still dangerous if an attacker can steer it to the wrong redirect_uri or borrow an approval through a weak session model. Expiry helps containment, while trust validation prevents misuse at the source.

Q: When should organisations block or constrain dynamic client registration?

A: Organisations should constrain dynamic client registration whenever the server cannot tightly verify callback destinations, user sessions, and approval context. If registration is needed, it should be policy-driven and limited to trusted patterns. Otherwise, the convenience of on-the-fly onboarding can become a route for attacker-controlled redirects and long-lived exposure.

Technical breakdown

Why Remote MCP and OAuth become fragile together

Remote MCP servers often sit between an AI client and a SaaS authorization server, which means the server must translate between MCP-native access and standard OAuth flows. In practice, that proxy pattern can create two identity layers: one for the MCP client and one for the upstream SaaS app. If the server uses a shared client_id, cached consent can collapse those layers into a single trust decision. That is where code leakage becomes possible, because the authorization response can be routed to the wrong redirect_uri if state, client identity, and session are not tightly bound.

Practical implication: Treat proxy-based MCP authentication as a high-risk identity boundary and review every shared client_id and redirect path.

How consent and state binding fail in MCP integrations

OAuth state is meant to stop cross-site request forgery by tying the authorization response to the session that initiated it. In MCP deployments, that protection weakens when the server treats consent as anonymous or uses generic prompts that do not expose the real client identity and destination. An attacker can pre-run the flow, capture a redirect, and then lure the victim into completing the wrong step. If the server does not bind state to a user session and validate the browser context at callback time, the authorization code can be delivered to the attacker instead of the legitimate user.

Practical implication: Require session-bound state validation and make consent screens show the client name and redirect destination.

Why redirect_uri restrictions matter more than they first appear

Dynamic Client Registration makes MCP easier to adopt, but it also opens a route for attacker-controlled redirect URIs unless the server constrains registration patterns. A permissive redirect model can let a malicious client register a callback endpoint that receives authorization codes meant for a different session. Even when a fix is applied, existing registrations may remain exposed if the enforcement only covers new clients. The architectural lesson is that authentication hardening must cover both registration-time policy and runtime callback enforcement.

Practical implication: Review registration policy for existing and newly created clients, not just future ones.

Threat narrative

Attacker objective: The attacker wants delegated access to the victim's SaaS account through the MCP server so they can use approved tools and data paths as the victim.

1. Entry begins when a victim follows a crafted authorization link that starts an MCP OAuth flow through a proxy-style server.
2. Escalation occurs when weak consent handling or broken state binding allows an authorization code to be redirected to an attacker-controlled endpoint.
3. Impact follows when the attacker exchanges the code for tokens and invokes MCP tools with the victim's granted SaaS permissions.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP OAuth proxying creates an identity blast radius problem, not just a login problem. When one shared OAuth client stands in for many downstream clients, consent caching and redirect handling can collapse isolation between users, sessions, and tools. That turns a single implementation flaw into a broad delegated-access exposure across the environment. Practitioners should treat this as a blast-radius design issue, not a narrow protocol bug.

Consent must be explicit, contextual, and session-bound or it becomes a phishing surface. Generic approval prompts do not give users enough information to distinguish a legitimate agent workflow from a malicious registration flow. The more the implementation hides client identity, redirect destination, or authorization context, the easier it becomes to abuse the user journey. NHI governance must therefore include human-visible consent controls, not just backend token checks.

Dynamic registration is only safe when it is constrained by policy. The convenience of on-the-fly client registration is obvious, but unconstrained redirect_uri handling turns convenience into a control gap. Enterprises should assume that any MCP server supporting dynamic registration needs allowlisting, callback validation, and lifecycle oversight. In NHI terms, registration is a privileged action and should be governed accordingly.

Ephemeral authorization is not the same as ephemeral trust. Short-lived codes and tokens do not reduce risk if the session that requested them cannot be reliably identified and verified. That distinction matters for agentic systems, where the machine may act quickly but the trust decision still needs durable accountability. Teams should govern the trust chain, not just the token lifetime.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and a further 47% saying they only have partial visibility, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• For a broader view of the control gap, see The 52 NHI breaches Report, which shows how identity failures repeatedly turn into downstream access compromise.

What this signals

With 1 in 4 organisations already investing in dedicated NHI security capabilities, this class of MCP weakness is moving from a niche protocol issue to a programme-level concern. Security teams should expect more pressure to prove who can register, approve, and reuse machine-to-machine access paths, especially where AI agents sit on top of SaaS OAuth.

Runtime consent governance: this is the control pattern that MCP adopters now need to formalise. If the approval flow cannot prove the user session, the client identity, and the callback target, then the organisation does not have a trustworthy authorisation process. That should trigger a review of agent onboarding, callback policy, and exception handling across the estate.

For practitioners

• Bind OAuth state to a real user session Validate that every authorization response matches the session cookie or equivalent browser context that initiated the flow, and reject callbacks that do not match.
• Show high-fidelity consent details Expose the client name, redirect destination, and requested scope in every approval screen so a user can spot malicious or unexpected authorizations.
• Restrict redirect_uri registration aggressively Allow only trusted callback patterns for MCP clients, and review existing registrations to make sure older clients were not left outside the new policy.
• Audit shared client_id usage across MCP flows Inventory every MCP server that proxies to an upstream SaaS authorization server and determine whether consent reuse could cross client boundaries.

Key takeaways

• Proxy-based MCP OAuth flows can turn ordinary consent reuse into a delegated-access takeover path.
• The core failure is identity and session binding, not token length or code lifetime alone.
• Enterprises should govern MCP registration, consent, and callback policy as part of NHI control design.

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 Proxy Architecture: An OAuth proxy architecture sits between a client and an upstream authorization server, translating one access request into another. This can simplify integration, but it also creates dual identity boundaries, shared client identifiers, and callback handling risks that must be controlled carefully.
• Authorization Code Injection: Authorization code injection is an attack where a valid code is steered to an attacker-controlled endpoint or session. In MCP and OAuth flows, it often succeeds when state, consent, and redirect_uri validation are not bound tightly enough to the originating user session.
• Consent Caching: Consent caching is when an authorization server remembers a previous approval for a client and suppresses future prompts. In proxy-based MCP deployments, that convenience can become a control gap if the cached decision applies to multiple downstream clients that the user never explicitly approved.

Deepen your knowledge

MCP OAuth flow hardening is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing controls for AI-connected SaaS access, it is worth exploring.

This post draws on content published by Obsidian Security: When MCP Meets OAuth: Common Pitfalls Leading to One-Click Account Takeover. Read the original.