For remote HTTP MCP servers, use the MCP authorization specification as an OAuth 2.1 profile: make the MCP server a protected resource, publish protected-resource metadata, discover the authorization server, use authorization code plus PKCE for user-delegated access, bind tokens to the intended MCP resource, and validate audience on every request. Keep downstream API tokens separate, request narrow scopes, and record user consent and tool execution as different events.
Tech
For remote HTTP MCP servers, use the MCP authorization specification as an OAuth 2.1 profile: make the MCP server a protected resource, publish protected-resource metadata, discover the authorization server, use authorization code plus PKCE for user-delegated access, bind tokens to the intended MCP resource, and validate audience on every request. Keep downstream API tokens separate, request narrow scopes, and record user consent and tool execution as different events.
Reviewed July 30, 2026: This guide uses the stable MCP 2026-07-28 authorization specification. The official release list marks that revision as latest and stable; the earlier RC remains listed separately as a prerelease.
At a glance
• Authentication proves which client, user, or workload is involved.
• Authorization decides what that identity may do through the MCP server.
• Protected-resource metadata tells clients which authorization servers protect an MCP endpoint.
• PKCE protects authorization-code flows, especially for public clients.
• Resource indicators and audience validation prevent a token for one server being replayed at another.
• The token received by an MCP server must not be passed unchanged to an upstream service.
The authorization architecture
The MCP authorization specification treats a protected MCP server as an OAuth resource server. The MCP client is an OAuth client. An authorization server authenticates the resource owner, obtains consent where required, and issues access tokens.
These roles can be operated by one organization, but they remain logically separate:
1. The MCP client requests a protected capability.
2. The MCP server returns 401 Unauthorized with a pointer to its protected-resource metadata.
3. The client reads that metadata to identify one or more authorization servers and supported scopes.
4. The client discovers authorization endpoints through OAuth authorization-server metadata or OpenID Connect discovery.
5. The user completes an authorization-code flow with PKCE.
6. The client sends the access token to the MCP server in the Authorization: Bearer header.
7. The MCP server validates the token, principal, audience, expiry, issuer, and required authorization before serving data or executing a tool.
Local stdio servers may inherit security from their process environment. For remote servers handling private data or side effects, unauthenticated access should be an explicit product decision.
Discovery and metadata mechanics
OAuth integration fails when clients must guess where authorization lives. The specification therefore relies on OAuth 2.0 Protected Resource Metadata for the MCP server to advertise its authorization servers and relevant resource information.
A protected resource can point the client to metadata through the WWW-Authenticate header on a 401 response. The client can also use the defined well-known location. The authorization server then exposes its own metadata so the client can locate authorization and token endpoints and understand supported capabilities.
The 2026-07-28 specification allows authorization-server discovery through OAuth metadata or OpenID Connect discovery and requires clients to handle the documented endpoint patterns. Test issuers that include path components; naive string concatenation is a common interoperability failure.
Client registration is a separate decision. OAuth Client ID Metadata Documents can describe a client through a URL-shaped identifier. Dynamic Client Registration may also be supported. Neither approach removes the authorization server’s responsibility to validate redirects and apply client policy.
Tokens, audience, and resource indicators
An access token is not a universal credential. The client includes a resource parameter identifying the MCP server in authorization and token requests. The server then verifies that a presented token was issued for it.
This audience binding addresses a serious failure mode: a malicious or compromised server persuades a client to present a token intended for another service. If resource indicators and audience checks are missing, the wrong server may replay the token.
Token passthrough creates a related confused-deputy risk. If the MCP server calls a CRM, storage platform, or payment API, it should obtain a separate token for that upstream resource. It must not forward the client’s MCP access token as though it were an upstream API token. The official MCP security guidance emphasizes this separation.
Use short-lived access tokens where practical, rotate refresh tokens for public clients, store tokens outside model context, and prevent credentials from appearing in tool results, traces, prompts, URLs, or logs.
Authentication decision table
Scenario: Local stdio server used by one desktop process; Preferred pattern: Environment or local process security; Main control: Restrict executable, configuration, and inherited credentials
Scenario: User asks an agent to read private CRM data; Preferred pattern: Authorization code with PKCE; Main control: User consent, audience-bound token, read scopes
Scenario: User asks an agent to update records; Preferred pattern: Delegated OAuth plus step-up or confirmation; Main control: Narrow write scope and action-level authorization
Scenario: Background service runs without a user; Preferred pattern: Client-credentials extension where supported; Main control: Workload identity, secret rotation, least privilege
Scenario: MCP server calls a downstream SaaS API; Preferred pattern: Separate upstream OAuth client and token; Main control: Never pass through the MCP token
Scenario: Public read-only information server; Preferred pattern: No auth may be acceptable; Main control: Rate limits, abuse controls, explicit public-data boundary
Consent is not tool approval
OAuth consent allows a client to obtain access under defined scopes. It does not mean the user approved every future tool call. A scope such as “manage calendar events” may cover many operations, but deleting a series or inviting external attendees can still require action-level confirmation.
Design at least three policy layers:
• Connection consent: May this client connect to this MCP server under these scopes?
• Tool eligibility: May this agent see or call this tool for the current user and context?
• Action approval: Does this specific invocation require confirmation because of its arguments or consequences?
Show the user the intended action, material parameters, affected system, and whether the operation is reversible. Approval should bind to those details. Reusing a vague approval for materially different arguments weakens consent.
Security and governance
Create an authorization record for every MCP server. Include canonical resource URI, accepted issuers, audiences, client-registration method, redirect URIs, scopes, token lifetime, refresh behavior, upstream dependencies, and data classifications.
Scopes should describe business capabilities rather than grant an entire platform by default. Separate read from write and routine operations from privileged operations. The resource server must still enforce record-level, tenant-level, and object-level permissions; OAuth scope alone may be too coarse.
Protect against:
• redirect URI manipulation and authorization-code interception;
• token theft through logs, query strings, model context, or browser storage;
• accepting a token issued for another audience;
• issuer mix-up when multiple authorization servers are supported;
• overbroad dynamic registration;
• scope escalation without explicit user interaction;
• stale user access after role or employment changes;
• replay of destructive or payment-related tool calls.
The 2026 specification adds issuer-response validation, issuer-bound stored client credentials, registration metadata rules, and step-up scope guidance. Implement these as dated requirements and retain interoperability tests for older servers.
Implementation checklist
• [ ] Decide whether the server is public, user-delegated, or workload-only.
• [ ] Assign a canonical MCP resource URI.
• [ ] Publish protected-resource metadata.
• [ ] Configure OAuth or OIDC authorization-server discovery.
• [ ] Register exact redirect URIs and require PKCE.
• [ ] Include the MCP resource indicator in authorization and token requests.
• [ ] Validate signature, issuer, audience, expiry, and authorization on every request.
• [ ] Define narrow read, write, admin, and high-consequence scopes.
• [ ] Keep MCP tokens outside prompts, tool outputs, URLs, and ordinary logs.
• [ ] Obtain separate credentials for every downstream resource.
• [ ] Add action-level confirmations beyond OAuth consent.
• [ ] Make write operations idempotent where possible.
• [ ] Log consent, token issuance, policy decisions, tool calls, and outcomes separately.
• [ ] Test revocation, expiry, refresh failure, role changes, and account removal.
• [ ] Test 2026 authorization behavior against any supported 2025 fallback.
Limitations and change risk
MCP’s authorization profile does not replace application permissions. A valid token can still be used incorrectly if a tool ignores tenant boundaries or record-level authorization. Conversely, a carefully permissioned tool can still expose sensitive output through model context.
OAuth support varies by MCP client and hosted platform. Some clients may not support every registration or discovery mechanism. Client-credentials support is an extension, not a reason to force a user-oriented flow into a background service.
The authorization specification is evolving. Pin the protocol version, cite the dated specification in security reviews, and retest interoperability before changing discovery or registration behavior.
For the operating policy around identities, approvals, and evidence, read AI agent governance for SMBs.
FAQs
Does every MCP server need OAuth?
No. Local stdio servers and deliberately public servers can use other security boundaries. Remote servers with private data or side effects generally need authenticated and authorized access.
Why is PKCE required?
PKCE binds the authorization request to the client that later exchanges the code. It reduces authorization-code interception and injection risks, particularly for public clients that cannot protect a client secret.
Can an MCP server use the user’s token to call a CRM?
Not by passing the same token through. The MCP server should obtain a separate token intended for the CRM or other upstream resource. Each token must have the correct audience.
Is OAuth consent enough for destructive tools?
No. OAuth consent grants scoped access to a client. Destructive, financial, externally visible, or difficult-to-reverse calls should have additional policy and confirmation.
What should be logged?
Log identity, consent, scope, authorization decision, tool name, material non-secret arguments, approval, outcome, and correlation identifiers. Do not log bearer tokens or secrets.
Get a 20-Minute AI Workflow Audit
AI Operator can trace a real workflow from user identity through OAuth, tool policy, confirmation, downstream access, and audit evidence before it reaches production.