Remote MCP tools need more than accurate names and JSON schemas. A client can request a valid tool while presenting the wrong token audience, insufficient scope or a customer identifier outside the caller’s tenant. This guide examines how MCP authorization relates to OAuth, client identity, server-side resource checks, delegated credentials and consent—while distinguishing the 2025-11-25 specification from the final 2026-07-28 protocol revision.

A well-described MCP tool is not an authorized MCP tool

Model Context Protocol helps a host discover resources and tools exposed by a server. Descriptive tool metadata can help Claude select the right operation, and JSON schemas can constrain arguments. Neither tells a protected service which real user is entitled to which record. That question belongs to the transport, identity and application authorization layers. A remote MCP deployment can therefore have beautiful tool definitions and still be unsafe if it accepts tokens issued for some other recipient, treats all logged-in users as administrators, or passes a downstream credential through untrusted clients.

Well-designed MCP tool interfaces describe argument schemas and distinguish protocol failures from business-level denials, but a valid schema cannot establish which real user may read a customer record. Remote deployment therefore needs additional identity and authorization controls. The server must verify token audience, required scopes and tenant-specific resource ownership, and must not become a confused deputy by passing another service’s credentials to an untrusted client.

MCP has evolved quickly. The 2025-11-25 specification established a set of authorization patterns including OAuth-based flows for protected HTTP resources. The MCP project released the final 2026-07-28 specification after an earlier release candidate, along with SDK updates and authorization hardening. A production design must state which specification and SDK it implements rather than mixing examples from several revisions and claiming universal compatibility.

Identify the principal, client and resource before choosing OAuth details

Imagine a fictitious knowledge-assistant application. A user signs in to the company’s portal and asks Claude to summarize permitted customer tickets. The host invokes a remote MCP server that connects to a ticketing platform. There are at least four distinct actors: the human user, the host/MCP client, the MCP resource server, and the downstream ticket system. An authorization decision must establish which actor is acting on whose behalf, which resource is requested and which permissions actually apply.

Authentication proves something about a principal, such as possession of a valid signed token. Authorization decides whether that principal may perform the requested operation on the requested resource. The two are not substitutes. A token with a valid signature can still be issued for the wrong audience, have insufficient scope, belong to an expired session, or represent a user who cannot access a particular customer. A service must validate all relevant claims and its own business policy rather than infer access from the presence of any bearer string.

In this example, tools can be separated into search_tickets, get_ticket and update_ticket. The first two can be read-only, with a scope and server-side resource filter that limits the tenant. The update operation should require a distinct permission, stronger audit and potentially user confirmation. Broadening every tool to a global support-admin credential would erase the distinctions that make this separation valuable.

Token audience and the prohibition on arbitrary passthrough

A common failure mode is token passthrough: an MCP server accepts an access token intended for another resource and forwards it to a downstream API as though it were a universal identity. This can create confused authority and conceal which party is responsible for validation. OAuth access tokens are not generic transferable proof that "the user is logged in everywhere." Tokens have intended recipients, lifetime and scopes; a resource server should accept those meant for it, not just tokens it can decode.

A secure architecture should validate issuer, expiration, audience and permitted scopes using the authorization server’s appropriate metadata and signing validation, then apply local object-level authorization. Where a downstream system needs separate credentials, use a documented delegation or token-exchange pattern supported by the actual identity infrastructure rather than simply forwarding the host’s original bearer credential. The availability and syntax of those patterns depend on the provider and the applicable MCP authorization spec revision.

Never include real tokens, refresh credentials or signing secrets in a model-visible tool result. Store secrets within the client, authorization server or trusted integration service under proper controls. A prompt containing "please authorize this" is not a replacement for an OAuth consent flow or a business transaction approval.

Consent is scoped to an operation and a resource

An OAuth login screen may ask the user to authorize a client for specified capabilities. That consent should communicate the relevant resource, intended action and privilege. A user accepting read access to a support queue should not unknowingly authorize writes across every tenant. Nor should a new tool added to a server automatically inherit broad access merely because the connection was already established.

Good product design separates connection establishment from consequential activity. Linking an account might allow a host to list allowed records; changing a financial or security record may still require contextual human confirmation and a server-side policy gate. Consent fatigue is also a risk: repeated vague prompts make it harder for users to recognize an unusual request. Scope selection should be narrow, stable and tied to meaningful capabilities rather than bundling all possible powers.

The Model Context Protocol project has documented OAuth Client ID Metadata Documents and extensions to support different client types and enterprise environments. These features can simplify interoperability, but implementation details should be chosen based on the deployed spec and SDK, not copied from documentation for a newer finalized protocol into an older production client. Where the identity platform lacks required features, recognize the compatibility constraint explicitly rather than inventing an ad hoc bypass.

Prevent a confused deputy at the application boundary

A confused deputy occurs when a more privileged component is tricked into using its authority for an actor or purpose that is not authorized. In a remote MCP deployment, this can happen when the server uses its own service account to fetch arbitrary customer records supplied by a less-privileged caller. The model’s tool input may contain a syntactically valid ticket ID, but the server still needs to verify that the authenticated user belongs to the right tenant and may view that ticket.

For a hypothetical denial test, tenant A’s agent requests ticket B-204 belonging to tenant B. The MCP schema accepts the identifier as a string; the authorization layer must reject it. The response should indicate an appropriate failure without disclosing hidden ticket content, internal token values or excessive account details. A second test should send the same call with the actual tenant B identity and confirm that legitimate access works. Rejecting every request would not demonstrate that the system is correctly authorized.

Bind cached results to the appropriate identity and resource scope. A cache key based only on "ticket number" can leak cross-tenant data even if fresh backend calls are authorized correctly. Similar care is needed for search indexes, document snippets and long-lived agent memory. An agent can accidentally surface an earlier user’s result if its application state is reused without isolation.

Local MCP and remote MCP have different exposure profiles

A local MCP server launched as a subprocess may use standard input/output and operate under the privileges of the local user or service. That model introduces installation trust, executable integrity, environment-variable exposure, local file access and package provenance questions. An HTTP-based remote MCP server introduces network transport, resource-server authorization, redirect and OAuth discovery surfaces, browser consent and tenant isolation. The two environments should not share a simplistic "secure because MCP" assessment.

For local integration, audit executable paths, dependencies, permissions and secrets available to the process. For remote integration, enforce HTTPS and the authentication requirements of the selected transport, validate redirect behavior and limit destinations when performing discovery. Do not let arbitrary user-controlled metadata send the host to loopback/private addresses or unrelated OAuth endpoints without the required security checks.

Tool descriptions and MCP resources are themselves lower-trust material when returned by an untrusted server. They can contain text that attempts to redirect the assistant to a different action. Keep installation approval and network permission outside the model where possible. A client that imports every advertised tool from an arbitrary server can inadvertently expand the action surface before a human has assessed it.

Error handling must preserve the security boundary

MCP distinguishes protocol-level errors from execution failures that reach a valid tool. For example, a malformed JSON-RPC request belongs to the protocol/error layer. A properly formed get_ticket call that is denied for insufficient rights should be handled as a tool/application outcome without leaking more sensitive information. The published MCP tool-error guidance and current spec should determine the exact wire format; do not improvise field names that might differ by SDK revision.

Retries deserve caution. An expired or unauthorized token should not trigger the agent to attempt the same operation through an unrelated higher-privilege tool. An update that timed out may have executed, so blindly resubmitting it with fresh credentials can cause a duplicate change. Use operation identifiers and trustworthy downstream status lookups for uncertain side effects. The model may report the need for reauthentication, but only the authorized client/identity flow should acquire credentials.

Test the connection as a security system

An effective test suite covers at least: valid allowed read; missing token; expired token; wrong-audience token; insufficient scope; valid token with wrong tenant/resource; revoked authorization; unsupported issuer or redirect; suspicious server metadata; concurrent request after scope reduction; and a timed-out write with an uncertain external receipt. These tests should run against controlled mock resources before deployment. Do not put customer data or actual tokens into tutorial fixtures.

Record the expected outcome at the right layer. A wrong-audience token should fail before a protected backend call occurs. A cross-tenant ticket must remain unreadable. A revoked connection must not continue returning cached protected content. A reauthentication flow should go through the authorized browser/identity experience rather than asking the model to collect an access token in conversation text.

Keep a versioned manifest: MCP protocol date, SDK/library version, authorization-server discovery configuration, client ID registration mode, allowed scopes, transport, server trust policy, tool catalog hash and test outcome. This allows a later migration to a new MCP spec revision to be evaluated rather than silently changing behavior.

Three failures reveal why a successful sign-in is insufficient. A token with the wrong audience must be rejected before a tool reaches the protected backend; a correctly issued token with inadequate scope cannot authorize a write; and a token with the expected scopes still cannot read another tenant’s ticket without resource-level permission. Keep those cases separate in test results so a transport fix never masks a broken authorization rule. An independent Architect Foundations practice scenario that supplies a valid-audience token for the wrong tenant still requires denial by the protected service; successful OAuth authentication cannot replace record ownership and operation-scope checks. A well-formed MCP tool description answers none of those questions by itself.

The architecture decision for Claude systems

Trace one protected tool call from start to finish. Claude may propose an action; MCP exposes the operation and transports its request; identity infrastructure authenticates the client and caller; and the protected service decides whether that caller may affect this particular resource. Good tool descriptions support selection, not authorization. A valid transport session can still carry a request for the wrong tenant, so per-record checks must survive independently of what the model was told.

Building on that distinction turns a generic MCP integration into a well-defined service boundary. It also gives reviewers concrete questions to ask before deployment: Who is the client, who is the user, who issued this token, for which audience and scopes, which tenant owns the data, and which system records the final side effect? If those questions have no answers, adding more MCP tools makes the architecture larger but not more trustworthy.