MCP Authorization with OAuth: A Resource-Server Guide

Put each responsibility on the right side

The official MCP authorization tutorial describes an OAuth-based flow for remote HTTP servers. A protected server can return an unauthorized response that points the client to protected-resource metadata. The client discovers the authorization server, completes an authorization flow, and presents an access token to the MCP endpoint.

Keep three roles separate. The authorization server authenticates the user and issues tokens. The MCP client initiates consent and presents the token. The MCP server is the resource server: it validates the token and enforces access to tools and resources. If the MCP server forwards the caller's token to a downstream API, the token can escape its intended audience and the server becomes a confused deputy.

Local stdio servers have a different credential shape; the tutorial notes they can use local or library-provided credentials instead of the remote browser flow. That difference belongs in the transport decision described in MCP stdio vs Streamable HTTP. It is not permission to inherit every credential from the host process.

The MCP OAuth control matrix

Scopes are coarse; action policy is precise

Design scopes around stable capability groups such as reading a resource family or invoking a bounded class of tools. Avoid a single scope that silently unlocks every current and future tool. Yet do not create a unique OAuth scope for every record either; that becomes difficult to consent to and operate. Use scopes as the outer capability envelope, then enforce record ownership, tenant membership, transaction limits, and approval rules in application code.

This matters because a model can propose tool arguments but cannot authorize them. OWASP's Excessive Agency guidance emphasizes minimizing extensions, permissions, and autonomy. A fluent model request never upgrades the caller's token, and retrieved content never becomes consent.

Separate read tools from write tools where possible. Require additional approval for irreversible, external, or high-impact operations. The human approval workflow guide explains how to preserve a paused action and resume it after a decision without reinterpreting the original request.

Authorization failure cases

• Token passthrough: the MCP server accepts a token intended for another service or forwards it downstream. Validate audience for the MCP resource and obtain separate downstream credentials.
• Authentication without authorization: a valid identity can invoke every tool. Map each operation to scopes and server-side object policy.
• Scope inflation over time: a broad “tools” scope gains new powers whenever a tool is added. Review capability changes as authorization changes.
• Tenant identity supplied by the model: the tool trusts a tenant ID from natural language. Derive tenant context from validated identity and owned server state.
• Consent mistaken for runtime approval: OAuth consent is not confirmation for a specific deletion, payment, or message. Add transaction-level approval where impact requires it.
• Secrets in traces: access tokens, authorization headers, or codes appear in logs. Redact them at ingestion and retain only safe token metadata.
• Revocation that never reaches caches: a server continues accepting cached entitlements after access changed. Define freshness and invalidation explicitly.

A fail-closed implementation sequence

1. Inventory resources and actions. List tools, resources, data classes, tenants, side effects, and downstream services. Assign an owner and risk tier to each operation.
2. Define the protected resource. Give the MCP endpoint a stable resource identifier and publish protected-resource metadata over HTTPS. Trust only explicitly configured authorization servers.
3. Configure the client flow. Use an authorization-code flow with appropriate proof and anti-forgery protections, exact redirect matching, and safe token storage. Keep tokens out of prompts and model-visible context.
4. Validate every request. Verify signature, issuer, intended audience, time bounds, and required scope before dispatch. Return a uniform denial and reveal no sensitive policy details.
5. Enforce operation policy. Resolve user and tenant from validated identity, validate tool arguments, apply object ownership and limits, and gate consequential actions. The least-privilege tool guide provides the companion permission review.
6. Test denials before success. Exercise wrong audience, wrong issuer, expired token, missing scope, cross-tenant object, replay, revoked access, and rejected approval. Confirm no tool side effect occurred.
7. Audit safely. Record request ID, principal class, client, resource, action, policy decision, and outcome. Redact bearer values and connect incidents to the MCP hardening controls.

Decision summary

Use OAuth to establish and constrain delegated access, then enforce resource and action policy at the server immediately before each operation. Validate the audience claim and granted scope, reject confused-deputy paths, and never treat successful protocol negotiation as authorization.