MCP Authorization Security: OAuth, Token Audience and Confused Deputies

Model Context Protocol authorization is easy to describe badly. Teams often say that an MCP server “uses OAuth,” then treat the security design as complete. OAuth is useful infrastructure, but its presence does not answer the questions that matter most: which client received the token, which server may accept it, whose authority the agent is exercising, which tool operation is permitted, and whether the downstream resource would make the same decision.

Those questions become urgent when an MCP server connects an AI assistant to customer records, source repositories, cloud administration, payments, messaging or internal knowledge. The model can choose tools and arguments dynamically. An attacker can influence that choice through direct requests or untrusted content. Authorization must therefore survive an adversarial workflow, not merely a successful login.

This guide explains how security and platform teams can evaluate MCP authorization without assuming that protocol compliance equals safe business authorization. It should be read alongside the broader MCP security testing guide and the AI agent authentication and authorization guide.

What MCP authorization is supposed to establish

Authorization governs whether an MCP client may access a protected MCP server and invoke the capabilities that server exposes. In remote deployments, this commonly involves OAuth-based discovery and access tokens. The current MCP authorization specification defines protocol requirements, but an enterprise implementation still has to decide how identities, scopes, tools and business resources map to policy.

There are at least four principals in a typical workflow: the human user, the AI application or host, the MCP client connection, and the MCP server or downstream service. There may also be a separate agent workload identity, an identity provider, an authorization server and several APIs behind the MCP server. If logs show only “MCP client called tool,” incident responders cannot determine who initiated the action or under what delegation.

A useful design retains both workload identity and initiating principal. The server should know which approved application made the request and, when applicable, which user authorized it. Neither identity should silently replace the other. A shared platform token may authenticate the application but erase user-level accountability. A user token passed everywhere may expose excessive privileges and allow token reuse against unintended services.

Token audience is a security boundary

An access token should be accepted only by the resource server for which it was issued. Audience restriction prevents a token obtained for one service from becoming a bearer credential for another. This sounds elementary, yet agent platforms create pressure to reuse credentials because one conversation may call many tools.

Consider an agent that can access a document MCP server and a finance MCP server. If both accept the same broad token, malicious document content could influence the agent to present that token to the finance service. The finance service may see a valid signature and scope while missing the fact that the token was issued for a different resource. The result is a confused-deputy path built from individually legitimate components.

Validate issuer, audience, expiry, client binding and authorized scope at every protected server. Do not rely on the client to select the correct destination. Where the identity architecture supports proof-of-possession or sender-constrained tokens, test that stolen token material cannot be replayed from another client. Keep token lifetimes proportionate to the task, and make revocation operational rather than theoretical.

During testing, obtain a token for server A and deliberately present it to server B. Change hostnames, resource indicators, tenants and environments. Try a development token against production. Verify the server rejects the request before tool execution and records a useful reason without logging the credential.

The confused-deputy problem in MCP

A confused deputy occurs when a component with legitimate authority is manipulated into using that authority for someone else's purpose. MCP systems are susceptible because an AI host may combine user intent, retrieved content, model reasoning and powerful tools. A server can authenticate the host correctly while the host has been influenced by an untrusted document or message.

OAuth consent does not eliminate this problem. A user may have approved access to a calendar, but that does not mean every webpage read by the agent may schedule meetings. A user may authorize repository access, but an issue description should not be able to direct the agent to exfiltrate secrets. Authorization needs context and consequence controls above the connection layer.

Reduce confused-deputy risk by separating capabilities, narrowing scopes, binding approval to exact operations and enforcing resource authorization downstream. High-impact tools should receive structured, validated parameters. The system that owns the record, payment or permission should remain the final policy authority. Prompt instructions and MCP tool descriptions are not security controls.

Test indirect influence explicitly. Place a synthetic instruction in a document or tool result, then observe whether the agent changes destination, selects a higher-impact tool or requests broader access. Record the complete path from untrusted input through token selection to the downstream decision. The indirect prompt-injection guide provides a deeper test model.

OAuth discovery and metadata trust

Dynamic discovery improves interoperability, but it also introduces metadata that affects where clients send users and credentials. Clients should validate authorization-server metadata, permitted issuers, redirect URIs and transport security. Discovery should not allow an untrusted MCP server to redirect authentication to an arbitrary host.

Treat server and authorization metadata as configuration with provenance. Pin or approve expected domains in managed environments. Monitor changes to endpoints, supported methods and keys. A valid HTTPS certificate proves control of a domain, not that the domain is an approved identity provider for your enterprise.

Redirect URI handling deserves adversarial tests. Attempt open redirects, alternate schemes, wildcard subdomains, loopback variations and case or encoding tricks. Verify state and PKCE protections where applicable. Confirm that callback errors do not expose authorization codes, tokens or sensitive request parameters in logs and browser history.

Scopes are necessary but rarely sufficient

Scopes express broad authorization, such as permission to read files or create tickets. They usually do not encode every object, field, tenant, purpose or transaction limit. An orders.write scope should not automatically allow changing every customer's order.

Map MCP tools to the minimum scopes they require, then apply object-level policy in the backend. Separate read, draft, submit, approve and administer operations. Avoid one “agent” scope that grows each time a tool is added. If a tool combines several consequences, split it into narrower operations or enforce policy on each branch.

Evaluate whether the model can influence security-sensitive parameters. Tenant, user and ownership should come from authenticated server state where possible. If the model proposes a resource identifier, treat it as an input to reauthorize, not proof of entitlement. Test identifier substitution, pagination, filters, bulk operations and nested objects.

Consent must match the real action

Human consent is meaningful only when the person can understand what will happen. Generic prompts such as “Allow agent to use finance tools?” are weak for consequential operations. A useful approval identifies the action, target, amount or data category, destination, expiry and whether the action can be reversed.

Bind approval cryptographically or transactionally to trusted parameters. If any material parameter changes, require a new decision. Render approval data from a trusted system, not from a model-generated natural-language summary. Otherwise the model can describe one action while submitting another.

Consent should also be revocable and observable. Test what happens when a user revokes access during an active session, changes role, leaves the organization or loses access to a resource. Cached policy and long-lived tokens frequently create a gap between administrative intent and actual enforcement.

Credential brokerage and token handling

The model should not receive raw access tokens. Keep credentials in a broker, host runtime or server-side connection layer. The model can request a capability, but trusted code should select the credential, destination and allowed operation. Redact secrets from prompts, traces, transcripts, analytics and error messages.

Credential exchange can narrow authority between layers. A broad user session might be exchanged for a short-lived, audience-bound token for one MCP server. The server can then use a separate downstream credential or delegated token. Document where identity context is preserved and where it is transformed.

Test token leakage through tool results, debugging endpoints, exception text and model context. Search retained transcripts for token formats and authorization headers. Simulate a malicious tool response asking the agent to repeat its configuration or credentials. A secure design should make compliance impossible because the model never possesses the secret.

Authorization at the tool and resource layers

Connection authorization answers whether a client may reach a server. Tool authorization answers whether it may invoke a particular capability. Resource authorization answers whether that operation may affect a particular object. All three are required.

A server that exposes both search_customers and issue_refund should not rely on the client UI to hide the refund tool. Enforce policy on the server. A permitted refund tool must still validate account ownership, transaction state, amount limits, operator role and fraud controls in the system of record.

Tool schemas should make boundaries explicit. Use constrained types, allowlists and server-derived identity. Reject unknown fields. Limit bulk size and destinations. Treat model-generated free text cautiously when it can become a query, path, command or message. The MCP tool-poisoning guide explains why descriptions and results also need trust controls.

A practical MCP authorization test plan

Start with an identity and token map: users, workloads, clients, servers, issuers, audiences, scopes, tools and downstream resources. For every transition, document what is authenticated, what is authorized, what is trusted and what evidence is retained.

Then run controlled negative tests:

1. Present a token to the wrong MCP server.
2. Reuse a token across development, staging and production.
3. Substitute user, tenant and object identifiers.
4. Invoke a tool hidden by the client directly.
5. Replay an approval after changing a consequential parameter.
6. Continue after user revocation or role change.
7. Trigger an operation using indirect prompt injection.
8. Attempt a tool call with an expired or reduced scope.
9. Force discovery metadata toward an unapproved authorization server.
10. Inspect logs and transcripts for leaked credentials.

For each case, preserve the request, identity context, policy decision, tool call, downstream response and observable effect. A refusal message from the agent is not proof that the backend rejected the operation.

What good evidence looks like

An authorization finding should state the expected boundary and show exactly where it failed. Include sanitized token claims—not the token itself—the initiating identity, client, target server, requested tool, resource identifier, policy result and downstream effect. Record whether the action was attempted, blocked or completed.

Evidence should distinguish protocol findings from business-authorization findings. An audience-validation failure is different from cross-tenant object access, even if one enabled the other. Where weaknesses can be composed, label the chain as replayed or inferred. This discipline makes remediation and retesting credible.

MCP authorization checklist

• Use approved authorization servers and validate discovery metadata.
• Validate issuer, audience, expiry and client binding at every server.
• Preserve both agent workload and initiating user identity.
• Issue short-lived, narrowly scoped credentials.
• Keep raw tokens outside model-visible context.
• Enforce tool access on the server, not only in the client.
• Reauthorize every resource and consequential action downstream.
• Bind approval to trusted, exact operation parameters.
• Propagate revocation and role changes quickly.
• Log decisions and effects without storing credentials.
• Test direct calls, replay, substitution and indirect influence.
• Retest whenever tools, scopes, issuers or routing change.

Frequently asked questions

Does OAuth make an MCP server secure?

No. OAuth can establish delegated access, but the implementation must still validate token audience, constrain scopes, authorize tools and resources, protect credentials and resist confused-deputy workflows.

Should an MCP server accept the user's existing access token?

Only when the token is explicitly intended for that server and the architecture has assessed the delegation risk. Passing broad tokens through multiple tools increases exposure. Audience-bound exchange is often safer.

Where should final authorization happen?

The MCP server should enforce connection and tool policy, while the downstream system that owns the business resource should enforce object and action authorization. Do not place the entire decision in prompts or the agent UI.

How often should MCP authorization be retested?

Retest after changes to identity providers, discovery, clients, servers, scopes, tools, downstream APIs or approval workflows. High-impact paths should also have recurring regression tests.

MCP authorization is secure when authority remains narrow, attributable and enforceable from login through final effect. The goal is not to stop agents from using tools; it is to ensure that every tool call carries only the authority justified by the current user, task and resource. For a broader architecture review, continue with the MCP gateway security guide or book a scoped Oxyne demonstration.