Limitations
Known limitations
OAuth token passthrough
Apollo MCP Server currently passes through OAuth tokens received from MCP clients directly to upstream GraphQL APIs.
This behavior violates the MCP Authorization specification, which states:
"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 separate token, issued by the upstream authorization server. The MCP server MUST NOT pass through the token it received from the MCP client."
Rationale
The decision to pass through tokens stems from practical enterprise requirements that conflict with the MCP specification:
Multi-user scenarios: Enterprise GraphQL APIs often require direct user identity to perform granular access control and tenant isolation.
Existing enterprise patterns: Many organizations have GraphQL APIs that depend on the original Authorization header to identify users and apply existing identity-based access controls.
Multi-tenant applications: Upstream APIs frequently need to read the Authorization header to identify the tenant and apply appropriate data filtering.
User context propagation: The MCP specification lacks clear guidance on how user/session/identity information should reach upstream APIs when they need to perform their own authorization logic.
Security implications
Token passthrough can lead to confused deputy vulnerabilities.
Upstream APIs might incorrectly trust tokens as if they were validated by the MCP server.
Tokens intended for the MCP server audience might be inappropriately used with different services.
However, if upstream APIs enforce proper audience (
audclaim) validation, they should reject inappropriately scoped tokens.
Recommended workaround
Use the MCP server only with GraphQL APIs that accept the same OAuth tokens and audiences
Ensure your OAuth authorization server issues tokens with appropriate audience claims for both the MCP server and upstream APIs
Verify that your upstream APIs properly validate token audiences
Consider the security implications in your threat model, especially regarding OAuth trust boundaries
Future plans
We plan to address this limitation in a future release by implementing proper token exchange or separate authentication flows for upstream APIs, while still supporting the enterprise requirement for user identity propagation.