Repository: modelcontextprotocol/modelcontextprotocol
Pull request #407: [spec] Auth: Confused deputy
Author: login: pcarleton
Created: 2025-04-24T11:57:15Z | Merged: 2025-04-30T06:06:46Z

<!-- Provide a brief summary of your changes -->

## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->

Breaking out of https://github.com/modelcontextprotocol/modelcontextprotocol/pull/387 to avoid merge conflicts. This adds a security consideration about the Confused Deputy problem mentioned in https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/265


Diff:
diff --git a/docs/specification/draft/basic/authorization.mdx b/docs/specification/draft/basic/authorization.mdx
index 4ad6202ab..3312f47fa 100644
--- a/docs/specification/draft/basic/authorization.mdx
+++ b/docs/specification/draft/basic/authorization.mdx
@@ -293,4 +293,16 @@ 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 mis-match 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](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#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.
+
+### 3.4 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. See [Security Best Practices 2.1](/specification/draft/basic/security_best_practices) for details.
+
+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).
diff --git a/docs/specification/draft/basic/security_best_practices.mdx b/docs/specification/draft/basic/security_best_practices.mdx
new file mode 100644
index 000000000..89b66cee8
--- /dev/null
+++ b/docs/specification/draft/basic/security_best_practices.mdx
@@ -0,0 +1,116 @@
+---
+title: Security Best Practices
+---
+
+## 1. Introduction
+
+### 1.1 Purpose and Scope
+
+This document provides security considerations for the Model Context Protocol (MCP), complementing the MCP Authorization specification. This document identifies security risks, attack vectors, and best practices specific to MCP implementations.
+
+The primary audience for this document includes developers implementing MCP authorization flows, MCP server operators, and security professionals evaluating MCP-based systems. This document should be read alongside the MCP Authorization specification and [OAuth 2.0 security best practices](https://datatracker.ietf.org/doc/html/rfc9700).
+
+## 2. Attacks and Mitigations
+
+This section gives a detailed description of attacks on MCP implementations, along with potential countermeasures.
+
+### 2.1 Confused Deputy Problem
+
+Attackers can exploit MCP servers proxying other resource servers, creating "[confused deputy](https://en.wikipedia.org/wiki/Confused_deputy_problem)" vulnerabilities.
+
+#### 2.1.1 Terminology
+
+**MCP Proxy Server**
+: An MCP server that connects MCP clients to third-party APIs, offering MCP features while delegating operations and acting as a single OAuth client to the third-party API server.
+
+**Third-Party Authorization Server**
+: Authorization server that protects the third-party API. It may lack dynamic client registration support, requiring MCP proxy to use a static client ID for all requests.
+
+**Third-Party API**
+: The protected resource server that provides the actual API functionality. Access to this 
+  API requires tokens issued by the third-party authorization server.
+
+**Static Client ID**
+: A fixed OAuth 2.0 client identifier used by the MCP proxy server when communicating with
+  the third-party authorization server. This Client ID refers to the MCP server acting as a client
+  to the Third-Party API. It is the same value for all MCP server to Third-Party API interactions regardless of
+  which MCP client initiated the request.
+
+#### 2.1.2 Architecture and Attack Flows
+
+##### 2.1.2.1 Normal OAuth proxy usage (preserves user consent)
+
+```mermaid
+sequenceDiagram
+    participant UA as User-Agent (Browser)  
+    participant MC as MCP Client
+    participant M as MCP Proxy Server
+    participant TAS as Third-Party Authorization Server
+
+    Note over UA,M: Initial Auth flow completed
+
+    Note over UA,TAS: Step 1: Legitimate user consent for Third Party Server
+
+    M->>UA: Redirect to third party authorization server
+    UA->>TAS: Authorization request (client_id: mcp-proxy)
+    TAS->>UA: Authorization consent screen
+    Note over UA: Review consent screen
+    UA->>TAS: Approve
+    TAS->>UA: Set consent cookie for client ID: mcp-proxy
+    TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+    UA->>M: 3P Authorization code
+    Note over M,TAS: Exchange 3P code for 3P token
+    Note over M: Generate MCP authorization code
+    M->>UA: Redirect to MCP Client with MCP authorization code
+
+    Note over M,UA: Exchange code for token, etc.
+```
+
+##### 2.1.2.3 Malicious OAuth proxy usage (skips user consent)
+
+```mermaid
+sequenceDiagram
+    participant UA as User-Agent (Browser)
+    participant M as MCP Proxy Server
+    participant TAS as Third-Party Authorization Server
+    participant A as Attacker
+
+
+    Note over UA,A: Step 2: Attack (leveraging existing cookie, skipping consent)
+    A->>M: Dynamically register malicious client, redirect_uri: attacker.com
+    A->>UA: Sends malicious link
+    UA->>TAS: Authorization request (client_id: mcp-proxy) + consent cookie
+    rect rgba(255, 17, 0, 0.67)
+    TAS->>TAS: Cookie present, consent skipped
+    end
+
+   TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+   UA->>M: 3P Authorization code
+   Note over M,TAS: Exchange 3P code for 3P token
+   Note over M: Generate MCP authorization code
+   M->>UA: Redirect to attacker.com with MCP Authorization code
+   UA->>A: MCP Authorization code delivered to attacker.com
+   Note over M,A: Attacker exchanges MCP code for MCP token
+   A->>M: Attacker impersonates user to MCP server
+```
+
+#### 2.1.3 Attack Description
+
+When an MCP proxy server uses a static client ID to authenticate with a third-party 
+authorization server that does not support dynamic client registration, the following 
+attack becomes possible:
+
+1. A user authenticates normally through the MCP proxy server to access the third-party API
+2. During this flow, the third-party authorization server sets a cookie on the user agent
+   indicating consent for the static client ID
+3. An attacker later sends the user a malicious link containing a crafted authorization request which contains a malicious redirect URI along with a new dynamically registered client ID
+4. When the user clicks the link, their browser still has the consent cookie from the previous legitimate request
+5. The third-party authorization server detects the cookie and skips the consent screen
+6. The MCP authorization code is redirected to the attacker's server (specified in the crafted redirect_uri during dynamic client registration)
+7. The attacker exchanges the stolen authorization code for access tokens for the MCP server without the user's explicit approval
+8. Attacker now has access to the third-party API as the compromised user
+
+#### 2.1.4 Mitigation
+
+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).


Reviews:
user: login: localden
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-26T17:56:05Z
user: login: D-McAdams
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-28T23:07:53Z
user: login: D-McAdams
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-28T23:41:18Z
user: login: localden
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-29T05:12:54Z
user: login: pcarleton
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-04-29T14:57:04Z
user: login: pcarleton
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-04-29T15:01:51Z
user: login: D-McAdams
state: APPROVED
author_association: NONE
submitted_at: 2025-04-29T23:14:24Z
user: login: localden
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-04-30T06:01:23Z

Review comments:
diff_hunk: @@ -297,3 +297,92 @@ Authorization servers **MUST** take precautions to prevent redirecting user agen
 
 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.
 
+### 3.4 Confused Deputy Problem
+
+An attacker can exploit configurations where an MCP server operates as a proxy in front of a third party resource server, leading to the confused deputy problem.
path: docs/specification/draft/basic/authorization.mdx
user: login: localden
body: ```suggestion
An attacker can exploit configurations where an MCP server operates as a proxy in front of another resource server, leading to the confused deputy problem.
```
created_at: 2025-04-24T22:25:25Z
author_association: CONTRIBUTOR
diff_hunk: @@ -297,3 +297,92 @@ Authorization servers **MUST** take precautions to prevent redirecting user agen
 
 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.
 
+### 3.4 Confused Deputy Problem
+
+An attacker can exploit configurations where an MCP server operates as a proxy in front of a third party resource server, leading to the confused deputy problem.
+
+#### 3.4.1 Terminology
+
+**MCP Proxy Server**
+: An MCP server that acts as an intermediary between MCP clients and a protected 
+  third-party API. The MCP proxy server provides MCP functionality while delegating
+API operations to a third-party API server.  The MCP proxy server acts as a single OAuth client to the third-party API server.
+
+**Third-Party Authorization Server**
+: The authorization server that protects access to the third-party API. This server may not
+  support dynamic client registration, requiring the MCP proxy server to use a single static 
+  client ID for all requests.
+
+**Third-Party API**
+: The protected resource server that provides the actual API functionality. Access to this 
+  API requires tokens issued by the third-party authorization server.
+
+**Static Client ID**
+: A fixed OAuth 2.0 client identifier used by the MCP proxy server when communicating with
+  the third-party authorization server, shared across all MCP clients.
+
+#### 3.4.2 Architecture and Attack Flow
+
+```mermaid
+sequenceDiagram
+    participant UA as User-Agent (Browser)  
+    participant MC as MCP Client
+    participant M as MCP Proxy Server
+    participant TAS as Third-Party Authorization Server
+    participant A as Attacker
+
+    Note over UA,M: Initial Auth flow completed
+
+    Note over UA,TAS: Step 1: Legitimate user consent for Third Party Server
+
+    M->>UA: Redirect to third party authorization server
+    UA->>TAS: Authorization request (client_id: mcp-proxy)
+    TAS->>UA: Authorization consent screen
+    Note over UA: Review consent screen
+    UA->>TAS: Approve
+    TAS->>UA: Set consent cookie for client ID: mcp-proxy
+    TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+    UA->>M: 3P Authorization code
+    Note over M,TAS: Exchange 3P code for 3P token
+    Note over M: Generate MCP authorization code
+    M->>UA: Redirect to MCP Client with MCP authorization code
+
+    Note over M,UA: Exchange code for token, etc.
+
+    Note over UA,A: Step 2: Attack (leveraging existing cookie)
+    A->>M: Dynamically register malicious client, redirect_uri: attacker.com
+    A->>UA: Sends malicious link
+    UA->>TAS: Authorization request (client_id: mcp-proxy) + consent cookie
+    TAS->>TAS: Cookie present, consent skipped
+
+   TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+   UA->>M: 3P Authorization code
+   Note over M,TAS: Exchange 3P code for 3P token
+   Note over M: Generate MCP authorization code
+   M->>UA: Redirect to attacker.com with MCP Authorization code
+   UA->>A: MCP Authorization code delivered to attacker.com
+   Note over M,A: Attacker exchanges MCP code for MCP token
+   A->>M: Attacker impersonates user to MCP server
+```
+
+#### 3.4.3 Attack Description
+
+When an MCP proxy server uses a static client ID to authenticate with a third-party 
+authorization server that does not support dynamic client registration, the following 
+attack becomes possible:
+
+1. A user authenticates normally through the MCP proxy server to access the third-party API
+2. During this legitimate flow, the third-party authorization server sets a cookie on the user agent
+   indicating consent for the static client ID
+3. An attacker later sends the user a malicious link containing a crafted authorization request
+4. When the user clicks the link, their browser still has the consent cookie from the previous legitimate request
+5. The third-party authorization server sees the cookie and skips the consent screen
path: docs/specification/draft/basic/authorization.mdx
user: login: localden
body: ```suggestion
5. The third-party authorization server detects the cookie and skips the consent screen
```
created_at: 2025-04-24T22:45:17Z
author_association: CONTRIBUTOR
diff_hunk: @@ -297,3 +297,92 @@ Authorization servers **MUST** take precautions to prevent redirecting user agen
 
 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.
 
+### 3.4 Confused Deputy Problem
+
+An attacker can exploit configurations where an MCP server operates as a proxy in front of a third party resource server, leading to the confused deputy problem.
+
+#### 3.4.1 Terminology
+
+**MCP Proxy Server**
+: An MCP server that acts as an intermediary between MCP clients and a protected 
+  third-party API. The MCP proxy server provides MCP functionality while delegating
+API operations to a third-party API server.  The MCP proxy server acts as a single OAuth client to the third-party API server.
+
+**Third-Party Authorization Server**
+: The authorization server that protects access to the third-party API. This server may not
+  support dynamic client registration, requiring the MCP proxy server to use a single static 
+  client ID for all requests.
+
+**Third-Party API**
+: The protected resource server that provides the actual API functionality. Access to this 
+  API requires tokens issued by the third-party authorization server.
+
+**Static Client ID**
+: A fixed OAuth 2.0 client identifier used by the MCP proxy server when communicating with
+  the third-party authorization server, shared across all MCP clients.
+
+#### 3.4.2 Architecture and Attack Flow
+
+```mermaid
+sequenceDiagram
+    participant UA as User-Agent (Browser)  
+    participant MC as MCP Client
+    participant M as MCP Proxy Server
+    participant TAS as Third-Party Authorization Server
+    participant A as Attacker
+
+    Note over UA,M: Initial Auth flow completed
+
+    Note over UA,TAS: Step 1: Legitimate user consent for Third Party Server
+
+    M->>UA: Redirect to third party authorization server
+    UA->>TAS: Authorization request (client_id: mcp-proxy)
+    TAS->>UA: Authorization consent screen
+    Note over UA: Review consent screen
+    UA->>TAS: Approve
+    TAS->>UA: Set consent cookie for client ID: mcp-proxy
+    TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+    UA->>M: 3P Authorization code
+    Note over M,TAS: Exchange 3P code for 3P token
+    Note over M: Generate MCP authorization code
+    M->>UA: Redirect to MCP Client with MCP authorization code
+
+    Note over M,UA: Exchange code for token, etc.
+
+    Note over UA,A: Step 2: Attack (leveraging existing cookie)
+    A->>M: Dynamically register malicious client, redirect_uri: attacker.com
+    A->>UA: Sends malicious link
+    UA->>TAS: Authorization request (client_id: mcp-proxy) + consent cookie
+    TAS->>TAS: Cookie present, consent skipped
+
+   TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+   UA->>M: 3P Authorization code
+   Note over M,TAS: Exchange 3P code for 3P token
+   Note over M: Generate MCP authorization code
+   M->>UA: Redirect to attacker.com with MCP Authorization code
+   UA->>A: MCP Authorization code delivered to attacker.com
+   Note over M,A: Attacker exchanges MCP code for MCP token
+   A->>M: Attacker impersonates user to MCP server
+```
+
+#### 3.4.3 Attack Description
+
+When an MCP proxy server uses a static client ID to authenticate with a third-party 
+authorization server that does not support dynamic client registration, the following 
+attack becomes possible:
+
+1. A user authenticates normally through the MCP proxy server to access the third-party API
+2. During this legitimate flow, the third-party authorization server sets a cookie on the user agent
+   indicating consent for the static client ID
+3. An attacker later sends the user a malicious link containing a crafted authorization request
+4. When the user clicks the link, their browser still has the consent cookie from the previous legitimate request
+5. The third-party authorization server sees the cookie and skips the consent screen
+6. The MCP authorization code is redirected to the attacker's server (specified in the crafted redirect_uri during dynamic client registration)
+7. The attacker exchanges the stolen authorization code for access tokens without the user's explicit approval
path: docs/specification/draft/basic/authorization.mdx
user: login: localden
body: ```suggestion
7. The attacker exchanges the stolen authorization code for access tokens for the MCP server without the user's explicit approval
8. Attacker now has access to the third-party API as the compromised user
```
created_at: 2025-04-24T22:47:16Z
author_association: CONTRIBUTOR
diff_hunk: @@ -297,3 +297,92 @@ Authorization servers **MUST** take precautions to prevent redirecting user agen
 
 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.
 
+### 3.4 Confused Deputy Problem
+
+An attacker can exploit configurations where an MCP server operates as a proxy in front of a third party resource server, leading to the confused deputy problem.
+
+#### 3.4.1 Terminology
+
+**MCP Proxy Server**
+: An MCP server that acts as an intermediary between MCP clients and a protected 
+  third-party API. The MCP proxy server provides MCP functionality while delegating
+API operations to a third-party API server.  The MCP proxy server acts as a single OAuth client to the third-party API server.
+
+**Third-Party Authorization Server**
+: The authorization server that protects access to the third-party API. This server may not
+  support dynamic client registration, requiring the MCP proxy server to use a single static 
+  client ID for all requests.
+
+**Third-Party API**
+: The protected resource server that provides the actual API functionality. Access to this 
+  API requires tokens issued by the third-party authorization server.
+
+**Static Client ID**
+: A fixed OAuth 2.0 client identifier used by the MCP proxy server when communicating with
+  the third-party authorization server, shared across all MCP clients.
+
+#### 3.4.2 Architecture and Attack Flow
+
+```mermaid
+sequenceDiagram
+    participant UA as User-Agent (Browser)  
+    participant MC as MCP Client
+    participant M as MCP Proxy Server
+    participant TAS as Third-Party Authorization Server
+    participant A as Attacker
+
+    Note over UA,M: Initial Auth flow completed
+
+    Note over UA,TAS: Step 1: Legitimate user consent for Third Party Server
+
+    M->>UA: Redirect to third party authorization server
+    UA->>TAS: Authorization request (client_id: mcp-proxy)
+    TAS->>UA: Authorization consent screen
+    Note over UA: Review consent screen
+    UA->>TAS: Approve
+    TAS->>UA: Set consent cookie for client ID: mcp-proxy
+    TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+    UA->>M: 3P Authorization code
+    Note over M,TAS: Exchange 3P code for 3P token
+    Note over M: Generate MCP authorization code
+    M->>UA: Redirect to MCP Client with MCP authorization code
+
+    Note over M,UA: Exchange code for token, etc.
+
+    Note over UA,A: Step 2: Attack (leveraging existing cookie)
+    A->>M: Dynamically register malicious client, redirect_uri: attacker.com
+    A->>UA: Sends malicious link
+    UA->>TAS: Authorization request (client_id: mcp-proxy) + consent cookie
+    TAS->>TAS: Cookie present, consent skipped
+
+   TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+   UA->>M: 3P Authorization code
+   Note over M,TAS: Exchange 3P code for 3P token
+   Note over M: Generate MCP authorization code
+   M->>UA: Redirect to attacker.com with MCP Authorization code
+   UA->>A: MCP Authorization code delivered to attacker.com
+   Note over M,A: Attacker exchanges MCP code for MCP token
+   A->>M: Attacker impersonates user to MCP server
+```
+
+#### 3.4.3 Attack Description
+
+When an MCP proxy server uses a static client ID to authenticate with a third-party 
+authorization server that does not support dynamic client registration, the following 
+attack becomes possible:
+
+1. A user authenticates normally through the MCP proxy server to access the third-party API
+2. During this legitimate flow, the third-party authorization server sets a cookie on the user agent
+   indicating consent for the static client ID
+3. An attacker later sends the user a malicious link containing a crafted authorization request
+4. When the user clicks the link, their browser still has the consent cookie from the previous legitimate request
+5. The third-party authorization server sees the cookie and skips the consent screen
+6. The MCP authorization code is redirected to the attacker's server (specified in the crafted redirect_uri during dynamic client registration)
+7. The attacker exchanges the stolen authorization code for access tokens without the user's explicit approval
+
+#### 3.4.4 Mitigation
+
+MCP proxy servers that use a static client ID for third-party services MUST require explicit 
+approval for each newly registered dynamic client before forwarding requests to the 
path: docs/specification/draft/basic/authorization.mdx
user: login: localden
body: ```suggestion
approval for each dynamically registered client before forwarding requests to the 
```
created_at: 2025-04-24T22:48:37Z
author_association: CONTRIBUTOR
diff_hunk: @@ -297,3 +297,10 @@ Authorization servers **MUST** take precautions to prevent redirecting user agen
 
 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.
 
+### 3.4 Confused Deputy Problem
+
+An attacker can exploit configurations where an MCP server acts as an intermediary between MCP clients and a protected third-party API, leading to the confused deputy problem. The attacker can acquire and exchange a stolen authorization code for access tokens for the MCP server without the user's consent. Consult [Security Best Practices section 2.1](/specification/draft/basic/security_best_practices) for a more detailed description.
+
+MCP proxy servers that use a static client ID for third-party services MUST require explicit 
+approval for each dynamically registered client before forwarding requests to the 
path: docs/specification/draft/basic/authorization.mdx
user: login: D-McAdams
body: The wording "explicit approval" is ambiguous about what constitutes approval. Suggested rephrasing: `MCP proxy servers that use a static client ID for third-party services MUST prompt the end user for consent for each dynamically registered client before forwarding the user to the third-party authorization server (where the third-party may also prompt for its own user consent).`
created_at: 2025-04-28T23:07:53Z
author_association: NONE
diff_hunk: @@ -0,0 +1,106 @@
+---
+title: Security Best Practices
+---
+
+## 1. Introduction
+
+### 1.1 Purpose and Scope
+
+This document provides security considerations for the Model Context Protocol (MCP), complementing the MCP Authorization specification. This document identifies security risks, attack vectors, and best practices specific to MCP implementations.
+
+The primary audience for this document includes developers implementing MCP authorization flows, MCP server operators, and security professionals evaluating MCP-based systems. This document should be read alongside the MCP Authorization specification and [OAuth 2.0 security best practices](https://datatracker.ietf.org/doc/html/rfc9700).
+
+## 2. Attacks and Mitigations
+
+This section gives a detailed description of attacks on MCP implementations, along with potential countermeasures.
+
+### 2.1 Confused Deputy Problem
+
+An attacker can exploit configurations where an MCP server operates as a proxy in front of another resource server, leading to the confused deputy problem.
+
+#### 2.1.1 Terminology
+
+**MCP Proxy Server**
+: An MCP server that acts as an intermediary between MCP clients and a protected 
+  third-party API. The MCP proxy server provides MCP functionality while delegating
+API operations to a third-party API server.  The MCP proxy server acts as a single OAuth client to the third-party API server.
+
+**Third-Party Authorization Server**
+: The authorization server that protects access to the third-party API. This server may not
+  support dynamic client registration, requiring the MCP proxy server to use a single static 
+  client ID for all requests.
+
+**Third-Party API**
+: The protected resource server that provides the actual API functionality. Access to this 
+  API requires tokens issued by the third-party authorization server.
+
+**Static Client ID**
+: A fixed OAuth 2.0 client identifier used by the MCP proxy server when communicating with
+  the third-party authorization server, shared across all MCP clients.
+
+#### 2.1.2 Architecture and Attack Flow
+
+```mermaid
+sequenceDiagram
+    participant UA as User-Agent (Browser)  
+    participant MC as MCP Client
+    participant M as MCP Proxy Server
+    participant TAS as Third-Party Authorization Server
+    participant A as Attacker
+
+    Note over UA,M: Initial Auth flow completed
+
+    Note over UA,TAS: Step 1: Legitimate user consent for Third Party Server
+
+    M->>UA: Redirect to third party authorization server
+    UA->>TAS: Authorization request (client_id: mcp-proxy)
+    TAS->>UA: Authorization consent screen
+    Note over UA: Review consent screen
+    UA->>TAS: Approve
+    TAS->>UA: Set consent cookie for client ID: mcp-proxy
+    TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+    UA->>M: 3P Authorization code
+    Note over M,TAS: Exchange 3P code for 3P token
+    Note over M: Generate MCP authorization code
+    M->>UA: Redirect to MCP Client with MCP authorization code
+
+    Note over M,UA: Exchange code for token, etc.
+
+    Note over UA,A: Step 2: Attack (leveraging existing cookie)
+    A->>M: Dynamically register malicious client, redirect_uri: attacker.com
+    A->>UA: Sends malicious link
+    UA->>TAS: Authorization request (client_id: mcp-proxy) + consent cookie
+    TAS->>TAS: Cookie present, consent skipped
+
+   TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+   UA->>M: 3P Authorization code
+   Note over M,TAS: Exchange 3P code for 3P token
+   Note over M: Generate MCP authorization code
+   M->>UA: Redirect to attacker.com with MCP Authorization code
+   UA->>A: MCP Authorization code delivered to attacker.com
+   Note over M,A: Attacker exchanges MCP code for MCP token
+   A->>M: Attacker impersonates user to MCP server
+```
+
+#### 2.1.3 Attack Description
+
+When an MCP proxy server uses a static client ID to authenticate with a third-party 
+authorization server that does not support dynamic client registration, the following 
+attack becomes possible:
+
+1. A user authenticates normally through the MCP proxy server to access the third-party API
+2. During this legitimate flow, the third-party authorization server sets a cookie on the user agent
+   indicating consent for the static client ID
+3. An attacker later sends the user a malicious link containing a crafted authorization request
+4. When the user clicks the link, their browser still has the consent cookie from the previous legitimate request
+5. The third-party authorization server detects the cookie and skips the consent screen
+6. The MCP authorization code is redirected to the attacker's server (specified in the crafted redirect_uri during dynamic client registration)
+7. The attacker exchanges the stolen authorization code for access tokens for the MCP server without the user's explicit approval
+8. Attacker now has access to the third-party API as the compromised user
+
+#### 2.1.4 Mitigation
+
+MCP proxy servers that use a static client ID for third-party services MUST require explicit 
+approval for each dynamically registered client before forwarding requests to the 
path: docs/specification/draft/basic/security_best_practices.mdx
user: login: D-McAdams
body: Similar comment as above about ambiguity of "explicit approval" 
created_at: 2025-04-28T23:41:18Z
author_association: NONE
diff_hunk: @@ -297,3 +297,10 @@ Authorization servers **MUST** take precautions to prevent redirecting user agen
 
 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.
 
+### 3.4 Confused Deputy Problem
+
+An attacker can exploit configurations where an MCP server acts as an intermediary between MCP clients and a protected third-party API, leading to the confused deputy problem. The attacker can acquire and exchange a stolen authorization code for access tokens for the MCP server without the user's consent. Consult [Security Best Practices section 2.1](/specification/draft/basic/security_best_practices) for a more detailed description.
path: docs/specification/draft/basic/authorization.mdx
user: login: localden
body: ```suggestion
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. See [Security Best Practices 2.1](/specification/draft/basic/security_best_practices) for details.
```
created_at: 2025-04-29T04:54:40Z
author_association: CONTRIBUTOR
diff_hunk: @@ -297,3 +297,10 @@ Authorization servers **MUST** take precautions to prevent redirecting user agen
 
 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.
 
+### 3.4 Confused Deputy Problem
+
+An attacker can exploit configurations where an MCP server acts as an intermediary between MCP clients and a protected third-party API, leading to the confused deputy problem. The attacker can acquire and exchange a stolen authorization code for access tokens for the MCP server without the user's consent. Consult [Security Best Practices section 2.1](/specification/draft/basic/security_best_practices) for a more detailed description.
+
+MCP proxy servers that use a static client ID for third-party services MUST require explicit 
+approval for each dynamically registered client before forwarding requests to the 
path: docs/specification/draft/basic/authorization.mdx
user: login: localden
body: Would trim this down a bit more:

```
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).
```
created_at: 2025-04-29T04:56:15Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,106 @@
+---
+title: Security Best Practices
+---
+
+## 1. Introduction
+
+### 1.1 Purpose and Scope
+
+This document provides security considerations for the Model Context Protocol (MCP), complementing the MCP Authorization specification. This document identifies security risks, attack vectors, and best practices specific to MCP implementations.
+
+The primary audience for this document includes developers implementing MCP authorization flows, MCP server operators, and security professionals evaluating MCP-based systems. This document should be read alongside the MCP Authorization specification and [OAuth 2.0 security best practices](https://datatracker.ietf.org/doc/html/rfc9700).
+
+## 2. Attacks and Mitigations
+
+This section gives a detailed description of attacks on MCP implementations, along with potential countermeasures.
+
+### 2.1 Confused Deputy Problem
+
+An attacker can exploit configurations where an MCP server operates as a proxy in front of another resource server, leading to the confused deputy problem.
path: docs/specification/draft/basic/security_best_practices.mdx
user: login: localden
body: ```suggestion
Attackers can exploit MCP servers proxying other resource servers, creating "[confused deputy](https://en.wikipedia.org/wiki/Confused_deputy_problem)" vulnerabilities.
```
created_at: 2025-04-29T04:59:34Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,106 @@
+---
+title: Security Best Practices
+---
+
+## 1. Introduction
+
+### 1.1 Purpose and Scope
+
+This document provides security considerations for the Model Context Protocol (MCP), complementing the MCP Authorization specification. This document identifies security risks, attack vectors, and best practices specific to MCP implementations.
+
+The primary audience for this document includes developers implementing MCP authorization flows, MCP server operators, and security professionals evaluating MCP-based systems. This document should be read alongside the MCP Authorization specification and [OAuth 2.0 security best practices](https://datatracker.ietf.org/doc/html/rfc9700).
+
+## 2. Attacks and Mitigations
+
+This section gives a detailed description of attacks on MCP implementations, along with potential countermeasures.
+
+### 2.1 Confused Deputy Problem
+
+An attacker can exploit configurations where an MCP server operates as a proxy in front of another resource server, leading to the confused deputy problem.
+
+#### 2.1.1 Terminology
+
+**MCP Proxy Server**
+: An MCP server that acts as an intermediary between MCP clients and a protected 
+  third-party API. The MCP proxy server provides MCP functionality while delegating
+API operations to a third-party API server.  The MCP proxy server acts as a single OAuth client to the third-party API server.
path: docs/specification/draft/basic/security_best_practices.mdx
user: login: localden
body: Can be trimmed down:

```
MCP proxy server connects MCP clients to third-party APIs,
offering MCP features while delegating operations and acting
as a single OAuth client to the third-party API server.
```
created_at: 2025-04-29T05:05:12Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,106 @@
+---
+title: Security Best Practices
+---
+
+## 1. Introduction
+
+### 1.1 Purpose and Scope
+
+This document provides security considerations for the Model Context Protocol (MCP), complementing the MCP Authorization specification. This document identifies security risks, attack vectors, and best practices specific to MCP implementations.
+
+The primary audience for this document includes developers implementing MCP authorization flows, MCP server operators, and security professionals evaluating MCP-based systems. This document should be read alongside the MCP Authorization specification and [OAuth 2.0 security best practices](https://datatracker.ietf.org/doc/html/rfc9700).
+
+## 2. Attacks and Mitigations
+
+This section gives a detailed description of attacks on MCP implementations, along with potential countermeasures.
+
+### 2.1 Confused Deputy Problem
+
+An attacker can exploit configurations where an MCP server operates as a proxy in front of another resource server, leading to the confused deputy problem.
+
+#### 2.1.1 Terminology
+
+**MCP Proxy Server**
+: An MCP server that acts as an intermediary between MCP clients and a protected 
+  third-party API. The MCP proxy server provides MCP functionality while delegating
+API operations to a third-party API server.  The MCP proxy server acts as a single OAuth client to the third-party API server.
+
+**Third-Party Authorization Server**
+: The authorization server that protects access to the third-party API. This server may not
path: docs/specification/draft/basic/security_best_practices.mdx
user: login: localden
body: Also can be trimmed down a bit:

```
Authorization server that protects the third-party API.
It may lack dynamic client registration support, requiring MCP
proxy to use a static client ID for all requests.
```
created_at: 2025-04-29T05:07:45Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,106 @@
+---
+title: Security Best Practices
+---
+
+## 1. Introduction
+
+### 1.1 Purpose and Scope
+
+This document provides security considerations for the Model Context Protocol (MCP), complementing the MCP Authorization specification. This document identifies security risks, attack vectors, and best practices specific to MCP implementations.
+
+The primary audience for this document includes developers implementing MCP authorization flows, MCP server operators, and security professionals evaluating MCP-based systems. This document should be read alongside the MCP Authorization specification and [OAuth 2.0 security best practices](https://datatracker.ietf.org/doc/html/rfc9700).
+
+## 2. Attacks and Mitigations
+
+This section gives a detailed description of attacks on MCP implementations, along with potential countermeasures.
+
+### 2.1 Confused Deputy Problem
+
+An attacker can exploit configurations where an MCP server operates as a proxy in front of another resource server, leading to the confused deputy problem.
+
+#### 2.1.1 Terminology
+
+**MCP Proxy Server**
+: An MCP server that acts as an intermediary between MCP clients and a protected 
+  third-party API. The MCP proxy server provides MCP functionality while delegating
+API operations to a third-party API server.  The MCP proxy server acts as a single OAuth client to the third-party API server.
+
+**Third-Party Authorization Server**
+: The authorization server that protects access to the third-party API. This server may not
+  support dynamic client registration, requiring the MCP proxy server to use a single static 
+  client ID for all requests.
+
+**Third-Party API**
+: The protected resource server that provides the actual API functionality. Access to this 
+  API requires tokens issued by the third-party authorization server.
+
+**Static Client ID**
+: A fixed OAuth 2.0 client identifier used by the MCP proxy server when communicating with
+  the third-party authorization server, shared across all MCP clients.
path: docs/specification/draft/basic/security_best_practices.mdx
user: login: localden
body: I am not sure "shared across all MCP clients" is the right framing here. It's used by the server to request access tokens _for the server_ (I don't think we're talking about them being passed upstream to the client)?
created_at: 2025-04-29T05:08:52Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,106 @@
+---
+title: Security Best Practices
+---
+
+## 1. Introduction
+
+### 1.1 Purpose and Scope
+
+This document provides security considerations for the Model Context Protocol (MCP), complementing the MCP Authorization specification. This document identifies security risks, attack vectors, and best practices specific to MCP implementations.
+
+The primary audience for this document includes developers implementing MCP authorization flows, MCP server operators, and security professionals evaluating MCP-based systems. This document should be read alongside the MCP Authorization specification and [OAuth 2.0 security best practices](https://datatracker.ietf.org/doc/html/rfc9700).
+
+## 2. Attacks and Mitigations
+
+This section gives a detailed description of attacks on MCP implementations, along with potential countermeasures.
+
+### 2.1 Confused Deputy Problem
+
+An attacker can exploit configurations where an MCP server operates as a proxy in front of another resource server, leading to the confused deputy problem.
+
+#### 2.1.1 Terminology
+
+**MCP Proxy Server**
+: An MCP server that acts as an intermediary between MCP clients and a protected 
+  third-party API. The MCP proxy server provides MCP functionality while delegating
+API operations to a third-party API server.  The MCP proxy server acts as a single OAuth client to the third-party API server.
+
+**Third-Party Authorization Server**
+: The authorization server that protects access to the third-party API. This server may not
+  support dynamic client registration, requiring the MCP proxy server to use a single static 
+  client ID for all requests.
+
+**Third-Party API**
+: The protected resource server that provides the actual API functionality. Access to this 
+  API requires tokens issued by the third-party authorization server.
+
+**Static Client ID**
+: A fixed OAuth 2.0 client identifier used by the MCP proxy server when communicating with
+  the third-party authorization server, shared across all MCP clients.
+
+#### 2.1.2 Architecture and Attack Flow
+
+```mermaid
+sequenceDiagram
+    participant UA as User-Agent (Browser)  
+    participant MC as MCP Client
+    participant M as MCP Proxy Server
+    participant TAS as Third-Party Authorization Server
+    participant A as Attacker
+
+    Note over UA,M: Initial Auth flow completed
+
+    Note over UA,TAS: Step 1: Legitimate user consent for Third Party Server
+
+    M->>UA: Redirect to third party authorization server
+    UA->>TAS: Authorization request (client_id: mcp-proxy)
+    TAS->>UA: Authorization consent screen
+    Note over UA: Review consent screen
+    UA->>TAS: Approve
+    TAS->>UA: Set consent cookie for client ID: mcp-proxy
+    TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+    UA->>M: 3P Authorization code
+    Note over M,TAS: Exchange 3P code for 3P token
+    Note over M: Generate MCP authorization code
+    M->>UA: Redirect to MCP Client with MCP authorization code
+
+    Note over M,UA: Exchange code for token, etc.
+
+    Note over UA,A: Step 2: Attack (leveraging existing cookie)
+    A->>M: Dynamically register malicious client, redirect_uri: attacker.com
+    A->>UA: Sends malicious link
+    UA->>TAS: Authorization request (client_id: mcp-proxy) + consent cookie
+    TAS->>TAS: Cookie present, consent skipped
+
+   TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+   UA->>M: 3P Authorization code
+   Note over M,TAS: Exchange 3P code for 3P token
+   Note over M: Generate MCP authorization code
+   M->>UA: Redirect to attacker.com with MCP Authorization code
+   UA->>A: MCP Authorization code delivered to attacker.com
+   Note over M,A: Attacker exchanges MCP code for MCP token
+   A->>M: Attacker impersonates user to MCP server
+```
+
+#### 2.1.3 Attack Description
+
+When an MCP proxy server uses a static client ID to authenticate with a third-party 
+authorization server that does not support dynamic client registration, the following 
+attack becomes possible:
+
+1. A user authenticates normally through the MCP proxy server to access the third-party API
+2. During this legitimate flow, the third-party authorization server sets a cookie on the user agent
path: docs/specification/draft/basic/security_best_practices.mdx
user: login: localden
body: ```suggestion
2. During this flow, the third-party authorization server sets a cookie on the user agent
```
created_at: 2025-04-29T05:09:27Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,106 @@
+---
+title: Security Best Practices
+---
+
+## 1. Introduction
+
+### 1.1 Purpose and Scope
+
+This document provides security considerations for the Model Context Protocol (MCP), complementing the MCP Authorization specification. This document identifies security risks, attack vectors, and best practices specific to MCP implementations.
+
+The primary audience for this document includes developers implementing MCP authorization flows, MCP server operators, and security professionals evaluating MCP-based systems. This document should be read alongside the MCP Authorization specification and [OAuth 2.0 security best practices](https://datatracker.ietf.org/doc/html/rfc9700).
+
+## 2. Attacks and Mitigations
+
+This section gives a detailed description of attacks on MCP implementations, along with potential countermeasures.
+
+### 2.1 Confused Deputy Problem
+
+An attacker can exploit configurations where an MCP server operates as a proxy in front of another resource server, leading to the confused deputy problem.
+
+#### 2.1.1 Terminology
+
+**MCP Proxy Server**
+: An MCP server that acts as an intermediary between MCP clients and a protected 
+  third-party API. The MCP proxy server provides MCP functionality while delegating
+API operations to a third-party API server.  The MCP proxy server acts as a single OAuth client to the third-party API server.
+
+**Third-Party Authorization Server**
+: The authorization server that protects access to the third-party API. This server may not
+  support dynamic client registration, requiring the MCP proxy server to use a single static 
+  client ID for all requests.
+
+**Third-Party API**
+: The protected resource server that provides the actual API functionality. Access to this 
+  API requires tokens issued by the third-party authorization server.
+
+**Static Client ID**
+: A fixed OAuth 2.0 client identifier used by the MCP proxy server when communicating with
+  the third-party authorization server, shared across all MCP clients.
+
+#### 2.1.2 Architecture and Attack Flow
+
+```mermaid
+sequenceDiagram
+    participant UA as User-Agent (Browser)  
+    participant MC as MCP Client
+    participant M as MCP Proxy Server
+    participant TAS as Third-Party Authorization Server
+    participant A as Attacker
+
+    Note over UA,M: Initial Auth flow completed
+
+    Note over UA,TAS: Step 1: Legitimate user consent for Third Party Server
+
+    M->>UA: Redirect to third party authorization server
+    UA->>TAS: Authorization request (client_id: mcp-proxy)
+    TAS->>UA: Authorization consent screen
+    Note over UA: Review consent screen
+    UA->>TAS: Approve
+    TAS->>UA: Set consent cookie for client ID: mcp-proxy
+    TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+    UA->>M: 3P Authorization code
+    Note over M,TAS: Exchange 3P code for 3P token
+    Note over M: Generate MCP authorization code
+    M->>UA: Redirect to MCP Client with MCP authorization code
+
+    Note over M,UA: Exchange code for token, etc.
+
+    Note over UA,A: Step 2: Attack (leveraging existing cookie)
+    A->>M: Dynamically register malicious client, redirect_uri: attacker.com
+    A->>UA: Sends malicious link
+    UA->>TAS: Authorization request (client_id: mcp-proxy) + consent cookie
+    TAS->>TAS: Cookie present, consent skipped
+
+   TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+   UA->>M: 3P Authorization code
+   Note over M,TAS: Exchange 3P code for 3P token
+   Note over M: Generate MCP authorization code
+   M->>UA: Redirect to attacker.com with MCP Authorization code
+   UA->>A: MCP Authorization code delivered to attacker.com
+   Note over M,A: Attacker exchanges MCP code for MCP token
+   A->>M: Attacker impersonates user to MCP server
+```
+
+#### 2.1.3 Attack Description
+
+When an MCP proxy server uses a static client ID to authenticate with a third-party 
+authorization server that does not support dynamic client registration, the following 
+attack becomes possible:
+
+1. A user authenticates normally through the MCP proxy server to access the third-party API
+2. During this legitimate flow, the third-party authorization server sets a cookie on the user agent
+   indicating consent for the static client ID
path: docs/specification/draft/basic/security_best_practices.mdx
user: login: localden
body: Is it really going to be the same client ID re-used across all clients? We're not requiring the MCP server to do an in-server registration of clients?
created_at: 2025-04-29T05:11:03Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,106 @@
+---
+title: Security Best Practices
+---
+
+## 1. Introduction
+
+### 1.1 Purpose and Scope
+
+This document provides security considerations for the Model Context Protocol (MCP), complementing the MCP Authorization specification. This document identifies security risks, attack vectors, and best practices specific to MCP implementations.
+
+The primary audience for this document includes developers implementing MCP authorization flows, MCP server operators, and security professionals evaluating MCP-based systems. This document should be read alongside the MCP Authorization specification and [OAuth 2.0 security best practices](https://datatracker.ietf.org/doc/html/rfc9700).
+
+## 2. Attacks and Mitigations
+
+This section gives a detailed description of attacks on MCP implementations, along with potential countermeasures.
+
+### 2.1 Confused Deputy Problem
+
+An attacker can exploit configurations where an MCP server operates as a proxy in front of another resource server, leading to the confused deputy problem.
+
+#### 2.1.1 Terminology
+
+**MCP Proxy Server**
+: An MCP server that acts as an intermediary between MCP clients and a protected 
+  third-party API. The MCP proxy server provides MCP functionality while delegating
+API operations to a third-party API server.  The MCP proxy server acts as a single OAuth client to the third-party API server.
+
+**Third-Party Authorization Server**
+: The authorization server that protects access to the third-party API. This server may not
+  support dynamic client registration, requiring the MCP proxy server to use a single static 
+  client ID for all requests.
+
+**Third-Party API**
+: The protected resource server that provides the actual API functionality. Access to this 
+  API requires tokens issued by the third-party authorization server.
+
+**Static Client ID**
+: A fixed OAuth 2.0 client identifier used by the MCP proxy server when communicating with
+  the third-party authorization server, shared across all MCP clients.
+
+#### 2.1.2 Architecture and Attack Flow
+
+```mermaid
+sequenceDiagram
+    participant UA as User-Agent (Browser)  
+    participant MC as MCP Client
+    participant M as MCP Proxy Server
+    participant TAS as Third-Party Authorization Server
+    participant A as Attacker
+
+    Note over UA,M: Initial Auth flow completed
+
+    Note over UA,TAS: Step 1: Legitimate user consent for Third Party Server
+
+    M->>UA: Redirect to third party authorization server
+    UA->>TAS: Authorization request (client_id: mcp-proxy)
+    TAS->>UA: Authorization consent screen
+    Note over UA: Review consent screen
+    UA->>TAS: Approve
+    TAS->>UA: Set consent cookie for client ID: mcp-proxy
+    TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+    UA->>M: 3P Authorization code
+    Note over M,TAS: Exchange 3P code for 3P token
+    Note over M: Generate MCP authorization code
+    M->>UA: Redirect to MCP Client with MCP authorization code
+
+    Note over M,UA: Exchange code for token, etc.
+
+    Note over UA,A: Step 2: Attack (leveraging existing cookie)
+    A->>M: Dynamically register malicious client, redirect_uri: attacker.com
+    A->>UA: Sends malicious link
+    UA->>TAS: Authorization request (client_id: mcp-proxy) + consent cookie
+    TAS->>TAS: Cookie present, consent skipped
+
+   TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+   UA->>M: 3P Authorization code
+   Note over M,TAS: Exchange 3P code for 3P token
+   Note over M: Generate MCP authorization code
+   M->>UA: Redirect to attacker.com with MCP Authorization code
+   UA->>A: MCP Authorization code delivered to attacker.com
+   Note over M,A: Attacker exchanges MCP code for MCP token
+   A->>M: Attacker impersonates user to MCP server
+```
+
+#### 2.1.3 Attack Description
+
+When an MCP proxy server uses a static client ID to authenticate with a third-party 
+authorization server that does not support dynamic client registration, the following 
+attack becomes possible:
+
+1. A user authenticates normally through the MCP proxy server to access the third-party API
+2. During this legitimate flow, the third-party authorization server sets a cookie on the user agent
+   indicating consent for the static client ID
+3. An attacker later sends the user a malicious link containing a crafted authorization request
path: docs/specification/draft/basic/security_best_practices.mdx
user: login: localden
body: ```suggestion
3. An attacker later sends the user a malicious link containing a crafted authorization request which contains a malicious redirect URI along with a new dynamically registered client ID
```
created_at: 2025-04-29T05:12:25Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,106 @@
+---
+title: Security Best Practices
+---
+
+## 1. Introduction
+
+### 1.1 Purpose and Scope
+
+This document provides security considerations for the Model Context Protocol (MCP), complementing the MCP Authorization specification. This document identifies security risks, attack vectors, and best practices specific to MCP implementations.
+
+The primary audience for this document includes developers implementing MCP authorization flows, MCP server operators, and security professionals evaluating MCP-based systems. This document should be read alongside the MCP Authorization specification and [OAuth 2.0 security best practices](https://datatracker.ietf.org/doc/html/rfc9700).
+
+## 2. Attacks and Mitigations
+
+This section gives a detailed description of attacks on MCP implementations, along with potential countermeasures.
+
+### 2.1 Confused Deputy Problem
+
+An attacker can exploit configurations where an MCP server operates as a proxy in front of another resource server, leading to the confused deputy problem.
+
+#### 2.1.1 Terminology
+
+**MCP Proxy Server**
+: An MCP server that acts as an intermediary between MCP clients and a protected 
+  third-party API. The MCP proxy server provides MCP functionality while delegating
+API operations to a third-party API server.  The MCP proxy server acts as a single OAuth client to the third-party API server.
+
+**Third-Party Authorization Server**
+: The authorization server that protects access to the third-party API. This server may not
+  support dynamic client registration, requiring the MCP proxy server to use a single static 
+  client ID for all requests.
+
+**Third-Party API**
+: The protected resource server that provides the actual API functionality. Access to this 
+  API requires tokens issued by the third-party authorization server.
+
+**Static Client ID**
+: A fixed OAuth 2.0 client identifier used by the MCP proxy server when communicating with
+  the third-party authorization server, shared across all MCP clients.
+
+#### 2.1.2 Architecture and Attack Flow
+
+```mermaid
+sequenceDiagram
+    participant UA as User-Agent (Browser)  
+    participant MC as MCP Client
+    participant M as MCP Proxy Server
+    participant TAS as Third-Party Authorization Server
+    participant A as Attacker
+
+    Note over UA,M: Initial Auth flow completed
+
+    Note over UA,TAS: Step 1: Legitimate user consent for Third Party Server
+
+    M->>UA: Redirect to third party authorization server
+    UA->>TAS: Authorization request (client_id: mcp-proxy)
+    TAS->>UA: Authorization consent screen
+    Note over UA: Review consent screen
+    UA->>TAS: Approve
+    TAS->>UA: Set consent cookie for client ID: mcp-proxy
+    TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+    UA->>M: 3P Authorization code
+    Note over M,TAS: Exchange 3P code for 3P token
+    Note over M: Generate MCP authorization code
+    M->>UA: Redirect to MCP Client with MCP authorization code
+
+    Note over M,UA: Exchange code for token, etc.
+
+    Note over UA,A: Step 2: Attack (leveraging existing cookie)
+    A->>M: Dynamically register malicious client, redirect_uri: attacker.com
+    A->>UA: Sends malicious link
+    UA->>TAS: Authorization request (client_id: mcp-proxy) + consent cookie
+    TAS->>TAS: Cookie present, consent skipped
+
+   TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
+   UA->>M: 3P Authorization code
+   Note over M,TAS: Exchange 3P code for 3P token
+   Note over M: Generate MCP authorization code
+   M->>UA: Redirect to attacker.com with MCP Authorization code
+   UA->>A: MCP Authorization code delivered to attacker.com
+   Note over M,A: Attacker exchanges MCP code for MCP token
+   A->>M: Attacker impersonates user to MCP server
+```
+
+#### 2.1.3 Attack Description
+
+When an MCP proxy server uses a static client ID to authenticate with a third-party 
+authorization server that does not support dynamic client registration, the following 
+attack becomes possible:
+
+1. A user authenticates normally through the MCP proxy server to access the third-party API
+2. During this legitimate flow, the third-party authorization server sets a cookie on the user agent
+   indicating consent for the static client ID
path: docs/specification/draft/basic/security_best_practices.mdx
user: login: pcarleton
body: this is the MCP server's client ID that it gets from e.g. the Github API (which doesn't support DCR).  So it will be the MCP server is acting as a client to the Github API with a static client ID, meanwhile MCP clients have different client ID's per client.
created_at: 2025-04-29T14:57:04Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,106 @@
+---
+title: Security Best Practices
+---
+
+## 1. Introduction
+
+### 1.1 Purpose and Scope
+
+This document provides security considerations for the Model Context Protocol (MCP), complementing the MCP Authorization specification. This document identifies security risks, attack vectors, and best practices specific to MCP implementations.
+
+The primary audience for this document includes developers implementing MCP authorization flows, MCP server operators, and security professionals evaluating MCP-based systems. This document should be read alongside the MCP Authorization specification and [OAuth 2.0 security best practices](https://datatracker.ietf.org/doc/html/rfc9700).
+
+## 2. Attacks and Mitigations
+
+This section gives a detailed description of attacks on MCP implementations, along with potential countermeasures.
+
+### 2.1 Confused Deputy Problem
+
+An attacker can exploit configurations where an MCP server operates as a proxy in front of another resource server, leading to the confused deputy problem.
+
+#### 2.1.1 Terminology
+
+**MCP Proxy Server**
+: An MCP server that acts as an intermediary between MCP clients and a protected 
+  third-party API. The MCP proxy server provides MCP functionality while delegating
+API operations to a third-party API server.  The MCP proxy server acts as a single OAuth client to the third-party API server.
+
+**Third-Party Authorization Server**
+: The authorization server that protects access to the third-party API. This server may not
+  support dynamic client registration, requiring the MCP proxy server to use a single static 
+  client ID for all requests.
+
+**Third-Party API**
+: The protected resource server that provides the actual API functionality. Access to this 
+  API requires tokens issued by the third-party authorization server.
+
+**Static Client ID**
+: A fixed OAuth 2.0 client identifier used by the MCP proxy server when communicating with
+  the third-party authorization server, shared across all MCP clients.
path: docs/specification/draft/basic/security_best_practices.mdx
user: login: pcarleton
body: ah I see, yea I meant "shared" as in "used for all of them", not necessarily exposed to them, will edit
created_at: 2025-04-29T15:01:50Z
author_association: MEMBER

PR comments:
user: login: pcarleton
created_at: 2025-04-24T12:03:15Z
body: Previous discussion:
https://github.com/modelcontextprotocol/modelcontextprotocol/pull/387#discussion_r2057013692

> @aaronpk: This section needs some cleanup on the terminology used. There's a few different terms being used to refer to the same things or aren't previously defined:
>
> * OAuth proxy
> * "...fronts an authorization server"
> * "backing authorization server"
> * "upstream API"
>
> We need to be much clearer about which roles we're talking about here. I would recommend starting with an abbreviated sequence diagram to show the relationships between the different parties, as well as a definition of each term, prior to discussing the attack.
author_association: MEMBER
user: login: geelen
created_at: 2025-04-29T01:35:48Z
body: This is great. One thing that took me a bit to get my head around when this was first raised was that it's the "cookie present, consent skipped" that makes the attack different from the normal third-party proxy OAuth flow.

<img width="294" alt="image" src="https://github.com/user-attachments/assets/66cf04c6-ad54-4004-be61-e059bb395d10" />

Not sure if it's possible to highlight this more explicitly for the user? Potentially breaking the diagram into two makes it easier to understand?

<details>

### Normal OAuth proxy usage (preserves user consent)

```mermaid
sequenceDiagram
    participant UA as User-Agent (Browser)  
    participant MC as MCP Client
    participant M as MCP Proxy Server
    participant TAS as Third-Party Authorization Server
    Note over UA,M: Initial Auth flow completed
    Note over UA,TAS: Step 1: Legitimate user consent for Third Party Server
    M->>UA: Redirect to third party authorization server
    UA->>TAS: Authorization request (client_id: mcp-proxy)
    TAS->>UA: Authorization consent screen
    Note over UA: Review consent screen
    UA->>TAS: Approve
    TAS->>UA: Set consent cookie for client ID: mcp-proxy
    TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
    UA->>M: 3P Authorization code
    Note over M,TAS: Exchange 3P code for 3P token
    Note over M: Generate MCP authorization code
    M->>UA: Redirect to MCP Client with MCP authorization code
    Note over M,UA: Exchange code for token, etc.
```

### Malicious OAuth proxy usage (skips user consent)

```mermaid
sequenceDiagram
    participant UA as User-Agent (Browser)  
    participant A as Attacker
    participant M as MCP Proxy Server
    participant TAS as Third-Party Authorization Server
    Note over UA,M: Step 2: Attack (leveraging existing cookie)
    A->>M: Dynamically register malicious client, redirect_uri: attacker.com
    A->>UA: Sends malicious link
    UA->>TAS: Authorization request (client_id: mcp-proxy) + consent cookie
    TAS->>TAS: Cookie present, consent skipped
   TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
   UA->>M: 3P Authorization code
   Note over M,TAS: Exchange 3P code for 3P token
   Note over M: Generate MCP authorization code
   M->>UA: Redirect to attacker.com with MCP Authorization code
   UA->>A: MCP Authorization code delivered to attacker.com
   Note over M,A: Attacker exchanges MCP code for MCP token
   A->>M: Attacker impersonates user to MCP server
```

</details>

I'm sure someone who is better at mermaid diagrams could do a decent job of that. But otherwise, this is great.

FWIW, I sketched out what an example consent dialog needs to look like: https://github.com/cloudflare/ai/pull/99. Not sure if there's a better place to leave examples like that, or whether it's something that should be added to the SDKs?
author_association: NONE
user: login: localden
created_at: 2025-04-29T04:52:49Z
body: @geelen we're working on bootstrapping a separate section for security-related documentation that should better accomodate examples such as the dialog you're referring to. FWIW, I took inspiration from that and am building something similar for our (Microsoft) samples as well since the problem is the same. This almost makes me think that we need a more generic solution here (outside teh scope of the spec).
author_association: CONTRIBUTOR
user: login: pcarleton
created_at: 2025-04-29T15:13:10Z
body: @geelen good call! I split it up and put a red rect over the cookie consent skipping to make it more obvious where the bad thing happens.

ty @dend  & @D-McAdams , ptal 
author_association: MEMBER