Skip to main content
This document outlines security requirements that implementers MUST consider when building MCP clients and servers. Additionally, implementors MUST follow OAuth 2.1 security best practices as outlined in OAuth 2.1 Section 7. “Security Considerations”.

​
Token Audience Binding and Validation

RFC 8707 Resource Indicators provide critical security benefits by binding tokens to their intended audiences when the Authorization Server supports the capability. To enable current and future adoption:
  • MCP clients MUST include the resource parameter in authorization and token requests as specified in the Resource Parameter Implementation section
  • MCP servers MUST validate that tokens presented to them were specifically issued for their use
The Security Best Practices document outlines why token audience validation is crucial and why token passthrough is explicitly forbidden.

​
Token Theft

Attackers who obtain tokens stored by the client, or tokens cached or logged on the server can access protected resources with requests that appear legitimate to resource servers. Clients and servers MUST implement secure token storage and follow OAuth best practices, as outlined in OAuth 2.1, Section 7.1. Authorization servers SHOULD issue short-lived access tokens to reduce the impact of leaked tokens. For public clients, authorization servers MUST rotate refresh tokens as described in OAuth 2.1 Section 4.3.1 “Token Endpoint Extension”.

​
Communication Security

Implementations MUST follow OAuth 2.1 Section 1.5 “Communication Security”. Specifically:
  1. All authorization server endpoints MUST be served over HTTPS.
  2. All redirect URIs MUST be either localhost or use HTTPS.

​
Authorization Code Protection

An attacker who has gained access to an authorization code contained in an authorization response can try to redeem the authorization code for an access token or otherwise make use of the authorization code. (Further described in OAuth 2.1 Section 7.5) To mitigate this, MCP clients MUST implement PKCE according to OAuth 2.1 Section 7.5.2 and MUST verify PKCE support before proceeding with authorization. PKCE helps prevent authorization code interception and injection attacks by requiring clients to create a secret verifier-challenge pair, ensuring that only the original requestor can exchange an authorization code for tokens. MCP clients MUST use the S256 code challenge method when technically capable, as required by OAuth 2.1 Section 4.1.1. Since OAuth 2.1 and PKCE specifications do not define a mechanism for clients to discover PKCE support, MCP clients MUST rely on authorization server metadata to verify this capability:
  • OAuth 2.0 Authorization Server Metadata: If code_challenge_methods_supported is absent, the authorization server does not support PKCE and MCP clients MUST refuse to proceed.
  • OpenID Connect Discovery 1.0: While the OpenID Provider Metadata does not define code_challenge_methods_supported, this field is commonly included by OpenID providers. MCP clients MUST verify the presence of code_challenge_methods_supported in the provider metadata response. If the field is absent, MCP clients MUST refuse to proceed.
Authorization servers providing OpenID Connect Discovery 1.0 MUST include code_challenge_methods_supported in their metadata to ensure MCP compatibility.

​
Mix-Up Attacks

An attacker that controls one of the authorization servers an MCP client interacts with may attempt to have the client send it an authorization code or token issued by a different, honest authorization server (a mix-up attack, described in RFC9207 Section 1). Authorization Response Validation specifies the required mitigation.

​
Open Redirection

An attacker may craft malicious redirect URIs to direct users to phishing sites. MCP clients MUST have redirect URIs registered with the authorization server. Authorization servers MUST validate exact redirect URIs against pre-registered values to prevent redirection attacks. MCP clients SHOULD use and verify state parameters in the authorization code flow and discard any results that do not include or have a mismatch with the original state. Authorization servers MUST take precautions to prevent redirecting user agents to untrusted URI’s, following suggestions laid out in OAuth 2.1 Section 7.12.2 Authorization servers SHOULD only automatically redirect the user agent if it trusts the redirection URI. If the URI is not trusted, the authorization server MAY inform the user and rely on the user to make the correct decision.

​
Client ID Metadata Document Security

When implementing Client ID Metadata Documents, authorization servers MUST consider the security implications detailed in OAuth Client ID Metadata Document, Section 6. Key considerations include:

​
Authorization Server Abuse Protection

Authorization servers fetching metadata documents SHOULD consider Server-Side Request Forgery (SSRF) risks, as described in OAuth Client ID Metadata Document: Server Side Request Forgery (SSRF) Attacks.

​
Localhost Redirect URI Risks

Client ID Metadata Documents cannot prevent localhost URL impersonation by themselves. Authorization servers:
  • SHOULD display additional warnings for localhost-only redirect URIs
  • MAY require additional attestation mechanisms for enhanced security
  • MUST clearly display the redirect URI hostname during authorization

​
Trust Policies

Authorization servers MAY implement domain-based trust policies for accepting Client ID Metadata Documents, as described in Section 6.4 and Section 6.8 of the Client ID Metadata Document specification.

​
Confused Deputy Problem

Attackers can exploit MCP servers acting as intermediaries to third-party APIs, leading to confused deputy vulnerabilities. By using stolen authorization codes, they can obtain access tokens without user consent. MCP proxy servers using static client IDs MUST obtain user consent for each dynamically registered client before forwarding to third-party authorization servers (which may require additional consent).

​
Access Token Privilege Restriction

An attacker can gain unauthorized access or otherwise compromise an MCP server if the server accepts tokens issued for other resources. MCP servers MUST validate access tokens before processing the request, ensuring the access token is issued specifically for the MCP server, and take all necessary steps to ensure no data is returned to unauthorized parties. A MCP server MUST follow the guidelines in OAuth 2.1 - Section 5.2 to validate inbound tokens. MCP servers MUST only accept tokens specifically intended for themselves and MUST reject tokens that do not include them in the audience claim or otherwise verify that they are the intended recipient of the token. See the Security Best Practices Token Passthrough section for details. If the MCP server makes requests to upstream APIs, it may act as an OAuth client to them. The access token used at the upstream API is a separate token, issued by the upstream authorization server. The MCP server MUST NOT pass through the token it received from the MCP client. MCP clients MUST implement and use the resource parameter as defined in RFC 8707 - Resource Indicators for OAuth 2.0 to explicitly specify the target resource for which the token is being requested. This requirement aligns with the recommendation in RFC 9728 Section 7.4. This ensures that access tokens are bound to their intended resources and cannot be misused across different services.