add details

Author: pcarleton

docs/specification/draft/basic/authorization.mdx

@@ -299,13 +299,88 @@ Authorization servers **SHOULD** only automatically redirect the user agent if i
 
 ### 3.4 Confused Deputy Problem
 
-An attacker can exploit OAuth proxy configurations that share third-party client credentials 
-across multiple users.
+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.
 
-When an MCP server fronts an authorization server that does not support dynamic client
-registration, the MCP server will use a static client ID to acquire credentials for the 
-upstream API.
+#### 3.4.1 Terminology
 
-If the the backing authorization server sets cookies after user consent, an attacker can craft malicious authorization requests that bypass consent flows for previously authorized applications.
+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.
 
-MCP servers using a static client_id for a backing service MUST require explicit approval for each newly registered dynamic client prior to forwarding requests to the backing authorization server for user consent.
+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: Store 3rd party access token
+    M->>UA: Redirect to MCP Client with MCP authorization code
+
+    Note over M,UA: Exchange code for token, use token
+
+    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: Store 3rd party access token
+   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 
+third-party authorization server for user consent. This ensures that each MCP client's 
+access is explicitly controlled at the proxy level.