Remote MCP Server Authentication with OAuth 2.1: A Practical Guide

A remote MCP server should treat authentication as a resource-server problem, not as a shared API-key shortcut. The client discovers the authorization server, obtains a resource-specific access token, sends it as a bearer token, and the MCP server validates issuer, audience, scopes, and expiry before processing a request.

Remote MCP versus local stdio authentication

Local stdio servers commonly receive credentials from the process environment because the client and server run together. A remote HTTP server has a network trust boundary and may serve many users or tenants, so it needs an authorization flow that can identify the resource, authorize the client, and constrain what the resulting token can access.

The actors in the flow

• MCP client: requests access to the remote server on behalf of a user or agent.
• MCP server: acts as the protected resource server and validates access tokens.
• Authorization server: authenticates the resource owner and issues tokens.
• Resource owner: the person or organization whose data or actions are protected.

1. Discover the authorization server

The MCP server advertises protected-resource metadata that identifies its authorization server. The client uses that metadata and the authorization-server metadata to learn the authorization endpoint, token endpoint, supported scopes, and PKCE capabilities. Keep the canonical MCP server URI consistent across discovery, authorization, and token requests.

2. Bind the token to the MCP resource

A resource indicator identifies which MCP server the token is intended for. This reduces the chance that a token issued for one resource will be accepted by another. The server must reject tokens that are not intended for it, even when the token is otherwise valid and signed.

Send the access token in the Authorization bearer header on every protected request. Do not put it in a query string, a URL, a page title, or an ordinary application log.

3. Protect the authorization-code flow

Public clients such as desktop and CLI applications should use authorization code flow with PKCE. Validate the state returned to the callback, use exact redirect URIs, require HTTPS except for approved localhost flows, and do not accept an authorization response from an unexpected issuer.

4. Validate every request

• Check that the bearer token is present and well-formed.
• Validate signature, issuer, expiry, and intended audience.
• Check scopes and tenant or subject policy for the requested tool.
• Return 401 for missing or invalid authentication and 403 for insufficient permission.
• Never put access tokens in query strings or logs.

5. Use separate credentials downstream

If the MCP server calls another API, treat that API as a separate trust boundary. Validate the token received from the client for the MCP resource, then use a separately issued downstream credential or an explicit delegated exchange. Do not forward the client’s token blindly.

Testing matrix

• No token: the server returns a safe 401 with the discovery hint.
• Expired token: the server rejects it without invoking the tool.
• Wrong audience: the server rejects it even if the signature is valid.
• Insufficient scope: the server returns 403 and does not perform the action.
• Valid read scope calling a write tool: policy denies the call.
• Two authorization servers: credentials are not reused across issuers.
• Multiple instances: every instance makes the same authorization decision.

Frequently asked questions