@rob-fusco @Cameron_Mayfield i forked the project and managed to forward the token, hope it would help you
3 Likes
@Maximiliano_Ozernick thanks for the fork!
@kevin_chu this fork demonstrates what I would be looking for in HTTP Authentication forwarding. The forwarding is implicit, but all of the GraphQL origin servers need the authentication for our use case.
2 Likes
Thanks everyone for the thoughtful discussion and contributions, especially @Maximiliano_Ozernick for sharing the fork and @JMGaia for bringing it to our attention.
After carefully reviewing the pull request, our team has decided not to support token passthrough in Apollo MCP Server. As @matthew.hawkins noted earlier, the MCP security best practices define token passthrough as an anti-pattern and explicitly forbid it. This restriction exists to prevent implicit trust between components, which can introduce serious security risks.
While we recognize the need for dynamic token handling, particularly in multi-tenant environments, we’re committed to solving this the right way. Our team is actively working on a proper authentication mechanism that follows OAuth 2.1 best practices and aligns with the MCP Authorization specification. Our goal is to deliver a secure, standards-compliant, and maintainable solution.
Thanks again for your engagement. It’s important to us to be transparent about these decisions.
6 Likes
We’ve added a section in our best practices docs explaining why the Apollo MCP server doesn’t support token passthrough:
2 Likes
I’m also in need of this feature, as my company heavily relies on JWTs as does many others. I understand the workflow proposed in the MCP Authorization Specification and where the breakdown is with lack of user consent.
Unfortunately, the Best Practices doesn’t provide a means to use the MCP Server with JWTs passed in from the client. Would be great to know how to use the MCP Server when interacting with real services that use Bearer Authentication.
Just a thought – similar to something like Node when using “NODE_TLS_REJECT_UNAUTHORIZED=0” , which creates a security vulnerability, could there be a flag that MCP implements the auth header passthrough and put the responsibility on the developers? Then deprecation of the flag when a proper auth mechanism is in place.
This is good news, hopefully we get this in Apollo MCP soon.
Looking at the Best Practices from Apollo:
Token passthrough forwards
Authorizationheaders 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.
And then looking at how Wondergraph describes Authentication:
The MCP server respects the “Authorization” header from MCP clients and forwards them to the router. This allows you to leverage all the authentication and authorization capabilities of your Cosmo Router when AI models interact with your GraphQL API.
I think highlighting the difference of where the MCP Server forwards the Authorization header would be useful in the Best Practices of Apollo MCP. That is, yes do not allow MCP Server to forward to downstream services. Rather, ensure they are forwarded to the Apollo Router for AuthN/Z validation. This is really the passthrough (at least for me) that is needed.
1 Like
Just for the sake of completeness of the ecosystem overview, Grafbase MCP also supports header forwarding. Docs here: MCP – Grafbase
It’s just one part of the June 2025 spec though, there is also the OAuth protected resource metadata (which is also supported , see docs link).
The MCP server is part of the Gateway, so the authentication logic of the Gateway applies, as well as all header rules as to what is forwarded to subgraphs, like for a regular GraphQL request. The token passthrough caveat doesn’t apply there because the Gateway acts as MCP server directly, it’s not passing it through to a downstream component.
We wrote a blog post on this: Announcing OAuth 2.1 support in the Grafbase MCP server
1 Like
@DaleSeo quickly revisiting header passing with the understanding that authentication will be OAuth2, will Apollo MCP support passing any headers?
Examples of use cases:
- Country passing from a CDN (AWS CloudFront uses CloudFront-Viewer-Country)
- Telemetry passing from a client (OTEL traceparent and tracestate)
The MCP server is not the edge in most cases is behind layer of infrastructure CDN->Load Balancer->Gateway ->etc.
@DaleSeo @matthew.hawkins @kevin_chu
Hey guys, we really like what you did so far, But without any authorization supported we cannot move forward to get even to EA anytime soon in our projects.
Do you have an ETA for at least a basic OAuth2 flow? so we can plan what to do
1 Like
I’m going to also iterate on this – not being able to seamlessly pass the auth headers from MCP to Router, really torpedoes all the great work the Apollo team has put into this. 
@Maximiliano_Ozernick OAuth support is coming very, very soon. We’re just finalizing a few things and it will then be in the next release.
Sorry I missed this earlier, @JMGaia. Your message got buried in the thread. After discussing those use cases further, we’ve identified an important distinction: token passthrough and header forwarding aren’t the same thing. Having said that, users could technically take an advantage of generic HTTP header propagation to pass API keys or tokens through, which is not recommended.
I see a few potential approaches:
- Leave header filtering to user discretion (maximum flexibility, higher risk)
- Block sensitive headers by default with opt-in overrides
- Provide configurable allowlists/blocklists for header forwarding
The core architectural question remains: what’s the best mechanism for LLMs to pass HTTP headers to MCP tools? Should this happen at the tool level, session level, or through the MCP protocol itself? Thoughts on which direction feels most promising?