Skip to content

Commit c3da075

Browse files
committed
consolidate warnings on token passthrough
1 parent 9850f92 commit c3da075

File tree

2 files changed

+7
-19
lines changed

2 files changed

+7
-19
lines changed

docs/source/best-practices.mdx

Lines changed: 0 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -27,17 +27,3 @@ In particular, we strongly recommend contract variants when using:
2727
If you register a persisted query with a specific client name instead of `null`, you must configure the MCP Server to send the necessary header indicating the client name to the router.
2828

2929
Use the `headers` option when running the MCP Server to pass the header to the router. The default name of the header expected by the router is `apollographql-client-name`. To use a different header name, configure `telemetry.apollo.client_name_header` in router YAML configuration.
30-
31-
## Avoid token passthrough for authentication
32-
33-
Token passthrough forwards `Authorization` headers from MCP clients through MCP Servers to downstream APIs. Although it might seem useful in some multi-tenant setups, the Apollo MCP Server intentionally does not support this pattern and we strongly discourage its use.
34-
35-
According to [MCP security best practices](https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices#token-passthrough) and the [MCP authorization specification](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization#access-token-privilege-restriction), this pattern introduces serious security risks:
36-
37-
- **Audience confusion**: If the MCP Server accepts tokens not intended for it, it can violate OAuth’s trust boundaries.
38-
- **Confused deputy problem**: If an unvalidated token is passed downstream, a downstream API may incorrectly trust it as though it were validated by the MCP Server.
39-
40-
To maintain clear trust boundaries, MCP servers must only accept tokens explicitly issued for themselves and must act as independent OAuth clients when calling upstream services.
41-
Forwarding client tokens downstream is not allowed.
42-
43-
Apollo MCP Server supports OAuth 2.1 authentication that follows best practices and aligns with the MCP authorization model. See our [authorization guide](/apollo-mcp-server/auth) for implementation details.

docs/source/config-file.mdx

Lines changed: 7 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -78,18 +78,20 @@ forward_headers:
7878

7979
<Caution>
8080

81-
Don't use header forwarding to pass through sensitive credentials such as API keys or access tokens. Forwarding credentials can introduce confused deputy vulnerabilities where your GraphQL API may incorrectly trust headers as though they were validated by the MCP Server.
81+
Don't use header forwarding to pass through sensitive credentials such as API keys or access tokens.
8282

8383
<br/><br/>
8484

85-
Header forwarding is intended for non-sensitive metadata like A/B testing, feature flagging, geo information from CDNs, or internal instrumentation.
85+
According to [MCP security best practices](https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices#token-passthrough) and the [MCP authorization specification](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization#access-token-privilege-restriction), token passthrough introduces serious security risks:
8686

87-
<br/><br/>
87+
- **Audience confusion**: If the MCP Server accepts tokens not intended for it, it can violate OAuth's trust boundaries.
88+
- **Confused deputy problem**: If an unvalidated token is passed downstream, a downstream API may incorrectly trust it as though it were validated by the MCP Server.
8889

89-
For passing through credentials, use the [auth configuration](#auth).
90+
<br/>
9091

91-
</Caution>
92+
Apollo MCP Server supports OAuth 2.1 authentication that follows best practices and aligns with the MCP authorization model. See our [authorization guide](/apollo-mcp-server/auth) for implementation details and how to use the [auth configuration](#auth).
9293

94+
</Caution>
9395

9496
### CORS
9597

0 commit comments

Comments
 (0)