Start with the job: implement authorization for a remote MCP server

Remote MCP authorization is an end-to-end token boundary, not a login button. The client requests access for the intended MCP resource, the server validates that audience and any upstream API receives its own appropriate credential.

Authentication alone does not prove a token was issued for this server or action. Accepting a token meant for another resource, or forwarding it unchanged upstream, creates confused-deputy and privilege risks.

Make the operating boundary visible

The versioned specification builds on OAuth 2.1 behavior, protected-resource discovery and resource indicators. Public clients use PKCE, redirect URIs are constrained, and the MCP server validates incoming access tokens before serving protected data.

FIG. 01 / Conceptual model

A token for one intended resource

Authorization trace from MCP client through authorization server to resource-bound MCP server token
Conceptual model: each access token is issued to and validated by its intended resource.

Build a reproducible path

For MCP Authorization for Remote Servers, use a small fixture that another developer can repeat without privileged production data. Change one boundary at a time and preserve the exact configuration needed to explain how the page's decision was reached.

  1. Identify the MCP resource and every upstream protected service.
  2. Publish or consume the required authorization metadata over HTTPS.
  3. Request a resource-bound token and validate issuer, audience and expiry at the server.
  4. Test consent, denial, expiry, revocation and a token issued for the wrong resource.

Keep secrets outside the mcp authorization artifact. Record variable names, scopes and owners, then verify the relevant system of record whenever this tool or workflow can change external state.

Record evidence that survives a rerun

Keep protocol captures sanitized and preserve authorization-server configuration separately from application logs. The review needs to show token audience and scope, not the token value.

  • MCP resource identifier and authorization server
  • Client type, redirect URI and PKCE behavior
  • Audience, scopes, lifetime and validation rules
  • Separate upstream token exchange or credential boundary

Date the MCP Authorization for Remote Servers record and keep factual observations separate from inference. If a claim depends on a hosted service, preview feature or moving SDK, name that dependency beside the claim.

Use a decision rule and a stopping rule

Approve the flow only when every token has one intended audience and the server can enforce its own resource boundary. Use a separate upstream authorization relationship instead of token passthrough.

Present an expired token, a token for another resource and a token missing required scope. None should return protected data; logs should identify the denial without storing bearer values.

FIG. 02 / Decision aid

Authorization failure gates

Decision matrix for MCP token audience, scope, expiry and upstream use
Decision aid: any audience, scope or validation failure blocks the protected call.

Protect against predictable failure and continue deliberately

For MCP Authorization for Remote Servers, the architecture review flags three recurring failure modes: specification versions are mixed; local and remote trust boundaries are conflated; a server is recommended without permission review. Treat them as release checks, not footnotes. This page remains draft when its exact implementation or intent evidence is still research-gated.

Use the MCP security threat model next: it traces data and tool access to concrete consequences.

Use the MCP prompt-injection model next: it shows how untrusted content can reach consequential tools.

Use the MCP field guide next: it reconnects the decision to protocol roles and versioned boundaries.