Merge branch 'main' into add-chorus-client

Author: cbh123

docs/specification/draft/basic/authorization.mdx

@@ -178,19 +178,58 @@ sequenceDiagram
         A->>C: Client Credentials
     end
 
-    Note over C: Generate PKCE parameters
-    C->>B: Open browser with authorization URL + code_challenge
-    B->>A: Authorization request
+    Note over C: Generate PKCE parameters<br/>Include resource parameter
+    C->>B: Open browser with authorization URL + code_challenge + resource
+    B->>A: Authorization request with resource parameter
     Note over A: User authorizes
     A->>B: Redirect to callback with authorization code
     B->>C: Authorization code callback
-    C->>A: Token request + code_verifier
+    C->>A: Token request + code_verifier + resource
     A->>C: Access token (+ refresh token)
     C->>M: MCP request with access token
     M-->>C: MCP response
     Note over C,M: MCP communication continues with valid token
 ```
 
+#### Resource Parameter Implementation
+
+MCP clients **MUST** implement Resource Indicators for OAuth 2.0 as defined in [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html)
+to explicitly specify the target resource for which the token is being requested. The `resource` parameter:
+
+1. **MUST** be included in both authorization requests and token requests.
+2. **MUST** identify the MCP server that the client intends to use the token with.
+3. **MUST** use the canonical URI of the MCP server as defined in [RFC 8707 Section 2](https://www.rfc-editor.org/rfc/rfc8707.html#name-access-token-request).
+
+##### Canonical Server URI
+
+For the purposes of this specification, the canonical URI of an MCP server is defined as the resource identifier as specified in
+[RFC 8707 Section 2](https://www.rfc-editor.org/rfc/rfc8707.html#section-2) and aligns with the `resource` parameter in
+[RFC 9728](https://datatracker.ietf.org/doc/html/rfc9728).
+
+MCP clients **SHOULD** provide the most specific URI that they can for the MCP server they intend to access, following the guidance in [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707). While the canonical form uses lowercase scheme and host components, implementations **SHOULD** accept uppercase scheme and host components for robustness and interoperability.
+
+Examples of valid canonical URIs:
+
+- `https://mcp.example.com/mcp`
+- `https://mcp.example.com`
+- `https://mcp.example.com:8443`
+- `https://mcp.example.com/server/mcp` (when path component is necessary to identify individual MCP server)
+
+Examples of invalid canonical URIs:
+
+- `mcp.example.com` (missing scheme)
+- `https://mcp.example.com#fragment` (contains fragment)
+
+> **Note:** While both `https://mcp.example.com/` (with trailing slash) and `https://mcp.example.com` (without trailing slash) are technically valid absolute URIs according to [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986), implementations **SHOULD** consistently use the form without the trailing slash for better interoperability unless the trailing slash is semantically significant for the specific resource.
+
+For example, if accessing an MCP server at `https://mcp.example.com`, the authorization request would include:
+
+```
+&resource=https%3A%2F%2Fmcp.example.com
+```
+
+MCP clients **MUST** send this parameter regardless of whether authorization servers support it.
+
 ### Access Token Usage
 
 #### Token Requirements
@@ -223,6 +262,8 @@ Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
 
 MCP servers, acting in their role as an OAuth 2.1 resource server, **MUST** validate access tokens as described in
 [OAuth 2.1 Section 5.2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-5.2).
+MCP servers **MUST** validate that access tokens were issued specifically for them as the intended audience,
+according to [RFC 8707 Section 2](https://www.rfc-editor.org/rfc/rfc8707.html#section-2).
 If validation fails, servers **MUST** respond according to
 [OAuth 2.1 Section 5.3](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-5.3)
 error handling requirements. Invalid or expired tokens **MUST** receive a HTTP 401
@@ -313,8 +354,11 @@ MCP servers **MUST** validate access tokens before processing the request, ensur
 
 A MCP server **MUST** follow the guidelines in [OAuth 2.1 - Section 5.2](https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-12.html#section-5.2) to validate inbound tokens.
 
-MCP servers **MUST** only accept tokens specifically intended for themselves.
+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 [Security Best Practices Section 2.2](/specification/draft/basic/security_best_practices#token-passthrough) 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 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.
+MCP clients **MUST** implement and use the `resource` parameter as defined in [RFC 8707 - Resource Indicators for OAuth 2.0](https://www.rfc-editor.org/rfc/rfc8707.html)
+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](https://datatracker.ietf.org/doc/html/rfc9728#section-7.4). This ensures that access tokens are bound to their intended resources and
+cannot be misused across different services.

docs/specification/draft/basic/security_best_practices.mdx

@@ -141,3 +141,90 @@ Token passthrough is explicitly forbidden in the [authorization specification](/
 #### Mitigation
 
 MCP servers **MUST NOT** accept any tokens that were not explicitly issued for the MCP server.
+
+### 2.3 Session Hijacking
+
+Session hijacking is an attack vector where a client is provided a session ID by the server, and an unauthorized party is able to obtain and use that same session ID to impersonate the original client and perform unauthorized actions on their behalf.
+
+#### 2.3.1 Session Hijack Prompt Injection
+
+```mermaid
+sequenceDiagram
+    participant Client
+    participant ServerA
+    participant Queue
+    participant ServerB
+    participant Attacker
+
+    Client->>ServerA: Initialize (connect to streamable HTTP server)
+    ServerA-->>Client: Respond with session ID
+
+    Attacker->>ServerB: Access/guess session ID
+    Note right of Attacker: Attacker knows/guesses session ID
+
+    Attacker->>ServerB: Trigger event (malicious payload, using session ID)
+    ServerB->>Queue: Enqueue event (keyed by session ID)
+
+    ServerA->>Queue: Poll for events (using session ID)
+    Queue-->>ServerA: Event data (malicious payload)
+
+    ServerA-->>Client: Async response (malicious payload)
+    Client->>Client: Acts based on malicious payload
+```
+
+#### 2.3.2 Session Hijack Impersonation
+
+```mermaid
+sequenceDiagram
+    participant Client
+    participant Server
+    participant Attacker
+
+    Client->>Server: Initialize (login/authenticate)
+    Server-->>Client: Respond with session ID (persistent session created)
+
+    Attacker->>Server: Access/guess session ID
+    Note right of Attacker: Attacker knows/guesses session ID
+
+    Attacker->>Server: Make API call (using session ID, no re-auth)
+    Server-->>Attacker: Respond as if Attacker is Client (session hijack)
+```
+
+#### 2.3.3 Attack Description
+
+When you have multiple stateful HTTP servers that handle MCP requests, the following attack vectors are possible:
+
+**Session Hijack Prompt Injection**
+
+1. The client connects to **Server A** and receives a session ID.
+1. The attacker obtains an existing session ID and sends a malicious event to **Server B** with said session ID.
+
+   - When a server supports [redelivery/resumable streams](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#resumability-and-redelivery), deliberately terminating the request before receiving the response could lead to it being resumed by the original client via the GET request for server sent events.
+   - If a particular server initiates server sent events as a consequence of a tool call such as a `notifications/tools/list_changed`, where it is possible to affect the tools that are offered by the server, a client could end up with tools that they were not aware were enabled.
+
+1. **Server B** enqueues the event (associated with session ID) into a shared queue.
+1. **Server A** polls the queue for events using the session ID and retrieves the malicious payload.
+1. **Server A** sends the malicious payload to the client as an asynchronous or resumed response.
+1. The client receives and acts on the malicious payload, leading to potential compromise.
+
+**Session Hijack Impersonation**
+
+1. The MCP client authenticates with the MCP server, creating a persistent session ID.
+2. The attacker obtains the session ID.
+3. The attacker makes calls to the MCP server using the session ID.
+4. MCP server does not check for additional authorization and treats the attacker as a legitimate user, allowing unauthorized access or actions.
+
+#### 2.3.4 Mitigation
+
+To prevent session hijacking and event injection attacks, the following mitigations should be implemented:
+
+MCP servers that implement authorization **MUST** verify all inbound requests.
+MCP Servers **MUST NOT** use sessions for authentication.
+
+MCP servers **MUST** use secure, non-deterministic session IDs.
+Generated session IDs (e.g., UUIDs) **SHOULD** use secure random number generators. Avoid predictable or sequential session identifiers that could be guessed by an attacker. Rotating or expiring session IDs can also reduce the risk.
+
+MCP servers **SHOULD** bind session IDs to user-specific information.
+When storing or transmitting session-related data (e.g., in a queue), combine the session ID with information unique to the authorized user, such as their internal user ID. Use a key format like `<user_id>:<session_id>`. This ensures that even if an attacker guesses a session ID, they cannot impersonate another user as the user ID is derived from the user token and not provided by the client.
+
+MCP servers can optionally leverage additional unique identifiers.