MCP OAuth Explained: Per-User Auth for AI Agents

---

What Is MCP OAuth

MCP OAuth is the authorization layer built into the Model Context Protocol. It applies OAuth 2.1 to the connection between an AI agent and an MCP server, so each person using the agent gets their own scoped, revocable access token instead of the agent authenticating with one shared credential for every user.

This authorization layer sits on top of a broader protocol, and the client-server model behind what MCP actually is is worth knowing before the mechanics below make full sense.

MCP Authentication vs MCP Authorization

This flow is commonly labeled MCP authentication in search and documentation, though the specification itself defines it as authorization. The client typically already knows who the person is before the flow starts. What OAuth adds is the delegated, scoped permission to act on that person’s behalf, plus a token the server can revoke independently of any other session.

Per-User Tokens vs Shared Access

A single API key set once in an environment variable works fine for a prototype with one user. It breaks the moment a second person connects, because every request now looks identical no matter who sent it, a narrower version of the wider architectural gap between MCP and a traditional API integration built around one static key.

Per-user OAuth solves this at the protocol level instead of the application level, one token per person instead of one key for everyone. Whether a given server actually implements that well, or just wraps a shared credential behind a proxy and calls it done, is the harder question, and it’s the one the rest of this piece works through.

---

MCP OAuth vs API Keys and OAuth Proxies

Multi-user access on an MCP server comes down to three models, a single shared API key, an OAuth proxy, or per-user OAuth. The first skips MCP OAuth entirely. The other two both implement it, just with very different guarantees, covered one at a time below.

Why Shared API Keys Fail for Multi-User AI Agents

A key shared across every user of the agent gives the server exactly one identity to work with, the application itself. That single identity creates three specific failures.

• It cannot distinguish between individual requests from different people.
• It cannot revoke one person’s access without cutting off everyone.
• It produces no record of who actually asked the agent to send an email or book a flight.

Security researchers describe this as a confused deputy problem. A program holding broad authority gets tricked into using it on behalf of whoever made the request, regardless of what that specific person is authorized to do.

How MCP OAuth Proxies Create a Shared-Identity Risk

The second model is an OAuth proxy. The MCP server registers once with the real identity provider using a single static client_id, then re-issues its own tokens to each connecting MCP client behind that one shared identity.

This is more secure than a bare API key, but it carries a specific weakness. From the downstream provider’s perspective, every user of every agent connected through that MCP server appears as the same application. That shared identity is the root cause behind the Square MCP breach detailed further down.

Why Per-User OAuth Fixes Both Problems

Per-user OAuth avoids both failure modes. Each person who connects an agent to an MCP server completes their own OAuth 2.1 flow and receives a token scoped to their own account. That access can be revoked individually, without affecting any other session.

Composio, which builds hosted per-user authentication for agent platforms, argues the access token should never reach the model’s context window at all, since a prompt injection attack could extract it directly from the conversation. Keeping the token inside a broker, with the model only requesting actions through that broker, removes that exposure entirely.

---

How the MCP OAuth 2.1 Flow Works

The specification’s authorization section breaks this exchange into six steps.

Step 1. MCP Server Returns a 401 Response: The MCP client calls a tool without a token. The server replies 401 Unauthorized with a WWW-Authenticate header pointing to its Protected Resource Metadata document.

Step 2. Client Discovers the Authorization Server: The client fetches that metadata, defined under RFC 9728, to learn the resource URI and which authorization server issues tokens for it, then fetches that authorization server’s own metadata (RFC 8414) for its authorize and token endpoints.

Step 3. MCP Client Registers: If the client hasn’t registered with this authorization server before, it uses Dynamic Client Registration (RFC 7591) or presents a Client ID Metadata Document, a static, URL-hosted alternative the spec added in its November 2025 update after DCR proved difficult to deploy at scale across real-world identity providers.

Step 4. Client Starts Authorization With PKCE: The client redirects the person’s browser to the authorization endpoint with a code_challenge. PKCE is mandatory under the spec. A server that doesn’t advertise code_challenge_methods_supported has to be refused outright rather than treated as optional.

Step 5. Person Approves the Requested Scopes: The person approves the specific scopes requested. The authorization server issues a code, and the client exchanges it, along with its code_verifier, for an access token bound to that one MCP server’s resource URI under RFC 8707.

Step 6. Client Makes Scoped Tool Calls: Every later tools/call request carries that token. The server validates the audience, checks the scope, and only then acts on the person’s behalf.

---

What Per-User OAuth Means for an Agent Talking to Multiple Servers

Real agents rarely talk to just one MCP server per person. A sales assistant might pull meeting notes from Zoom, log activity in Salesforce, and check inventory in an internal system, all for the same person, in the same session. Per-user OAuth has to hold up across that entire set of connections, the same challenge that shows up in building production multi-agent workflows with MCP and A2A once more than one server enters the picture.

One Token Per Server, Not One Token for the Agent

Engineers building this describe it as a two-hop problem. The first hop authenticates the person to the MCP server itself. The second hop is the MCP server calling downstream tools on that person’s behalf, and each downstream tool needs its own token for that same person. A production setup stores those tokens encrypted, keyed by both the person’s identity and the specific service, not by the person alone.

A VS Code bug report from February 2026 shows what happens when that keying goes wrong in a shipped client. Connecting to two separate Atlassian MCP servers for two different company sites, the client stored one shared credential, because it keyed tokens by server URL origin instead of by the full, distinct server identity. The second site’s connection kept reusing the first site’s token, the opposite of what per-user, per-server OAuth is supposed to guarantee. It’s a reminder that even VS Code’s own native MCP and GitHub Copilot integration can trip on this, and it’s one of the more mature client implementations out there.

Refreshing Tokens Without Breaking a Running Task

Each connected server’s token expires on its own schedule. An agent partway through a multi-step task, three tool calls into a five-call sequence, can have one server’s token expire while the others remain valid. The client has to refresh that one connection without interrupting the rest of the session.

Where those tokens live between sessions matters too. Desktop MCP clients typically rely on the operating system’s own credential store, the macOS Keychain, Windows Credential Manager, or an encrypted file on Linux, so a person doesn’t have to reauthorize every server every time they reopen the app, whether that’s Claude Desktop or another client holding the session.

Asking for More Access Mid-Task

Sometimes the token an agent already holds isn’t enough. A task that started as read-only can hit a step that needs write access partway through. The spec handles this with a step-up flow. The server returns 403 Forbidden with a challenge listing the exact scopes required, the client requests only those additional scopes, and the person approves the narrower addition rather than a broad new grant.

The spec also defines a URL-based elicitation mode built specifically for mid-session authorization requests like this. A server generates an authorization URL for a specific person to click. If that link reaches the wrong person instead, whoever clicks it completes the OAuth flow under their own identity, while the resulting token gets bound to whoever the request was originally meant for. The spec requires servers to verify that the person completing the flow is the same person who triggered it, the same binding failure behind the account takeover pattern covered next.

---

The One-Click Account Takeover Risk in MCP OAuth Proxies

The proxy pattern in the table above caused real account takeovers in production.

The Square MCP Account Takeover Case

Between July and August 2025, researchers at Obsidian Security disclosed one-click account takeover vulnerabilities in production remote MCP servers from several well-known vendors, including Square’s server at mcp.squareup.com. That server used dynamic client registration without redirect URI restrictions, paired with a single static client_id when talking to Square’s own authorization server.

An attacker could start their own authorization flow, capture the redirect toward Square’s login page before completing it, then send that captured link to a victim. Because Square’s authorization server already trusted that static client_id from an earlier legitimate consent, it skipped the consent screen entirely and handed the attacker a code scoped to the victim’s merchant account, transaction history, and bank details.

Why OAuth Proxy Vulnerabilities Still Occur

Vendors fixed the disclosed issues by late September 2025, and the MCP specification itself was updated on November 25, 2025 with explicit guidance on binding OAuth state to real user sessions.

In a test of 660 authorization server endpoints, Obsidian found that only 27, about 4 percent, actually supported the dynamic client registration the original spec assumed every provider would offer. Client ID Metadata Documents, the safer static alternative the spec now favors, fared worse in a separate, smaller test. Fewer than 4 percent of 78 tested authorization servers supported it. Low adoption of both mechanisms is what keeps teams reaching for the proxy shortcut, the exact gap that MCP’s broader security hardening push around NSA and CISA guidance is trying to close.

MCP OAuth Security Checks Before Connecting a Server

Evaluating an MCP server against this pattern means checking three things directly before connecting production credentials.

• Does its authorization server bind the state parameter to a real user session?
• Does it use the __Host- cookie prefix, so a subdomain takeover can’t inject a forged session?
• Does dynamic registration restrict redirect URIs to a known allowlist instead of accepting whatever a client sends?

---

How MCP Gateways Handle Per-User OAuth

Where per-user OAuth applies, a gateway sits in the position of the MCP server in the flow described above. It has to decide whether to run one shared client_id per connected tool or broker a separate token for each connected account, a decision that only gets harder once a gateway also has to absorb the stateless rework in the 2026-07-28 spec.

How MCP360 Handles Per-User OAuth

MCP360 is a unified gateway that connects AI agents to more than 100 external tools and custom MCP servers through one integration. As of this writing, it lists OAuth 2.0 and API key authentication with token rotation and audit logging among its controls, and the platform states it is SOC 2 Type II, GDPR, and ISO 27001 compliant.

Questions to Ask Before Choosing an MCP Gateway

The three questions below apply to any gateway, not only MCP360.

• Does it issue a separate token per connected person, or one shared identity for everyone who connects through it?
• Can access be revoked for a single person without disrupting every other session running through the same gateway?
• Does it produce an audit trail that ties a specific action back to the specific person who authorized it?

These map directly to the three columns in the comparison table earlier in this piece. This is a checklist, not a formality. A gateway that dodges the middle question is usually running the OAuth proxy model with better marketing, whatever it calls itself.

A failed connection partway through this handshake is usually a configuration mismatch rather than a broken OAuth implementation, the same distinction that runs through the most common MCP server connection failures more generally.

---

MCP OAuth Changes in the 2026 Specification

The version of the spec covered above, dated November 25, 2025, remains current today. The next revision, informally named for its target ship date of July 28, 2026, had its release candidate locked in May 2026, with the final specification due out on that same July date.

New Authorization Security Requirements

Six proposals in that release specifically harden authorization. Clients will have to validate the iss parameter on authorization responses per RFC 9207, closing a mix-up attack class that’s more relevant to MCP’s pattern of one client talking to many servers than to typical single-provider OAuth. Clients will also declare their OpenID Connect application_type during registration, fixing a recurring failure where an authorization server defaults a desktop or CLI client to “web” and rejects its localhost redirect URI outright. That’s one slice of a much larger overhaul. What breaks for server authors migrating to the stateless core in the same release is a separate, bigger question worth its own read.

MCP’s New Governance Model

Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation in December 2025, making the spec a vendor-neutral standard rather than one company’s roadmap, continuing a trajectory traced in MCP’s evolution since its 2025 debut.

Future MCP Authentication and Authorization Proposals

The broader 2026 roadmap lists deeper security and authorization work as an open area, including early proposals for DPoP, proof-of-possession tokens that can’t be replayed if stolen, and workload identity federation for service-to-service calls, the same push already killing static API keys elsewhere in agent infrastructure. None of that is finalized yet. For a production deployment today, build against the current 2025-11-25 spec and revisit the auth layer once 2026-07-28 ships as final.

---

Frequently Asked Questions

What is MCP OAuth?

MCP OAuth is the authorization layer built into the Model Context Protocol, using OAuth 2.1 so each person connecting an AI agent to a tool gets a scoped, revocable token instead of one shared credential. It governs a client’s 401 discovery, PKCE-protected consent, and RFC 8707 token binding to a specific MCP server, giving the server a per-person identity for every tool call.

What is the difference between MCP authentication and MCP authorization?

MCP authentication confirms who a person is, typically before the OAuth flow even starts. MCP authorization, which is what MCP OAuth actually governs, determines what that already-identified person is allowed to do and issues the scoped token that proves it. The two terms get used interchangeably in search and documentation, but only authorization is what the MCP OAuth flow itself performs.

Why can’t a single API key support multiple users in an AI agent?

A single shared API key gives an MCP server exactly one identity, the application itself, so it cannot tell one person’s request from another’s. It cannot revoke one person’s access without cutting off everyone using the agent, and it leaves no record of who actually triggered a given action, a pattern security researchers call a confused deputy problem.

What is an MCP OAuth proxy and why is it risky?

An MCP OAuth proxy registers once with a real identity provider using a single static client_id, then re-issues its own tokens to every connecting user behind that one shared identity. Downstream providers see every user as the same application, which is the exact weakness that caused real one-click account takeover vulnerabilities in production MCP servers disclosed in 2025.

How does the MCP OAuth 2.1 flow work step by step?

An unauthenticated request gets a 401 response pointing to Protected Resource Metadata, which tells the client which authorization server to use. The client registers, starts a PKCE-protected authorization request, and exchanges the resulting code for an access token bound to that one server. Gateways like MCP360 handle this exchange on behalf of every connected server rather than each server managing it separately.

Can one AI agent manage OAuth tokens for multiple MCP servers at once?

Yes, and it has to store a separate token per server, not one token for the whole agent, keyed by both the person and the specific service. Each server’s token expires on its own schedule, so refreshing one connection can’t interrupt the others. Confirm whether the specific gateway involved, such as MCP360, issues a distinct per-person token for each connected server rather than one shared identity across all of them.

What caused the MCP OAuth account takeover vulnerabilities in 2025?

Obsidian Security disclosed one-click account takeover vulnerabilities in remote MCP servers, including Square’s, between July and August 2025. The root cause was the OAuth proxy pattern combined with a failure to bind OAuth state to real user sessions, letting an attacker capture an authorization code meant for a victim. Vendors fixed the disclosed issues by late September 2025.

How do I know if an MCP gateway supports true per-user OAuth?

Check whether it issues a separate, revocable token per connected person or routes everyone through one shared client_id, whether it produces an audit trail tied to the specific person who acted, and whether one person’s access can be revoked without disrupting anyone else. MCP360, for example, lists OAuth 2.0 and API key authentication with token rotation and audit logging among its controls.

---

Conclusion

Per-user OAuth is an architecture decision, not a hardening pass bolted on after a security review flags it. Retrofitting token scoping into infrastructure built around one shared identity is a bigger rebuild than most teams plan for, and by the time that gap surfaces, it’s usually a customer or an auditor who finds it first, not the team that shipped it.

Before connecting any MCP server to real user accounts, including a first-party one, run it through the three questions above, per-person tokens, isolated revocation, a real audit trail. Check those answers against MCP360’s own OAuth 2.0 setup at mcp360.ai/docs before the next server gets added to your stack, not after.