Update the spec

Author: localden

docs/specification/draft/basic/authorization.mdx

@@ -307,11 +307,7 @@ An attacker can gain unauthorized access or otherwise compromise a MCP server if
 This vulnerability has two critical dimensions:
 
 1. **Audience validation failures.** When an MCP server doesn't verify that tokens were specifically intended for it (for example, via the audience claim, as mentioned in [RFC9068](https://www.rfc-editor.org/rfc/rfc9068.html)), it may accept tokens originally issued for other services. This breaks a fundamental OAuth security boundary, allowing attackers to reuse legitimate tokens across different services than intended.
-2. **Token passthrough.** If the MCP server not only accepts tokens with incorrect audiences but also forwards these unmodified tokens to downstream services, it introduces the "confused deputy" risk, outlined in [Section 3.4](#34-confused-deputy-problem). The MCP server becomes an unintentional proxy that can:
-  1. Enable privilege escalation across service boundaries
-  1. Facilitate lateral movement through connected resources
-  1. Allow circumvention of security controls between services
-  1. Enable replay attacks against multiple backend systems
+2. **Token passthrough.** If the MCP server not only accepts tokens with incorrect audiences but also forwards these unmodified tokens to downstream services, it can potentially cause the "confused deputy" problem, outlined in [Section 3.4](#34-confused-deputy-problem), where the downstream API may incorrectly trust the token as if it came from the MCP server or assume the token was validated by the upstream API. See [Security Best Practices 2.2](/specification/draft/basic/security_best_practices) for additional details.
 
 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.
 
@@ -322,5 +318,3 @@ MCP servers **MUST** only accept tokens specifically intended for themselves.
 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 seperate token, issued by the upstream authorization server. The MCP server **MUST NOT** pass through the token it received from the MCP client.
 
 If the authorization server supports the `resource` parameter, it is recommended that implementers follow [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html) to prevent token misuse.
-
-

docs/specification/draft/basic/security_best_practices.mdx

@@ -114,3 +114,28 @@ attack becomes possible:
 
 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).
+
+### 2.2 Token passthrough
+
+"Token passtrough" is an antipattern where a MCP server accepts tokens from a MCP client without validating that the tokens were properly issued _to the MCP server_ and "passing them through" to the downstream API.
+
+#### 2.2.1 Risks
+
+Token passthrough is explicitly forbidden in the [authorization specification](/specification/draft/basic/authorization) as it introduces a number of security risks, that include:
+
+- **Security Control Circumvention**
+  - The MCP Server or downstream APIs might implement important security controls like rate limiting, request validation, or traffic monitoring, that depend on the token audience or other credential constraints. If clients can obtain and use tokens directly with the downstream APIs without the MCP server validating them properly or ensuring that the tokens are issued for the right service, they bypass these controls. Service-specific tokens may be accepted by unintended services because no proper validation was performed.
+  - If the MCP Server passes tokens without validating their claims (e.g., roles, privileges, or audience) or other metadata, a malicious or compromised user can craft a token with elevated privileges and use the server as a proxy for data exfiltration.
+  - If the token is accepted by multiple services without proper validation, an attacker compromising one service can use the token to access other connected services.
+- **Accountability and Audit Trail Issues**
+  - The MCP Server will be unable to identify or distinguish between MCP Clients when clients are calling with an upstream-issued access token which may be opaque to the MCP Server.
+  - The downstream Resource Server's logs will show requests coming from client IDs that might not match the actual identity of the MCP server that is proxying the tokens.
+  - Both factors make incident investigation, controls, and auditing more difficult.
+- **Trust Boundary Issues**
+  - The downstream Resource Server grants trust to specific entities. This trust might include assumptions about origin or client behavior patterns. Breaking this trust boundary could lead to unexpected issues.
+- **Future Compatibility Risk**
+  - Even if an MCP Server starts as a "pure proxy" today, it might need to add security controls later. Starting with proper token audience separation makes it easier to evolve the security model.
+
+#### 2.2.2 Mitigation
+
+MCP servers **MUST NOT** accept any tokens that were not explicitly issued for the MCP server.