Apollo MCP Server

--- title: Limitations --- ## Known limitations ### OAuth token passthrough Apollo MCP Server currently passes through OAuth tokens received from MCP clients directly to upstream GraphQL APIs. #### Rationale The decision to pass through tokens stems from practical enterprise requirements that may conflict with the MCP specification. For example: - **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 (`aud` claim) 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 token exchange or separate authentication flows for upstream APIs, while still supporting the enterprise requirement for user identity propagation.