Any roadmap to support authorization headers soon?

MCP Server
23

@rob-fusco @Cameron_Mayfield i forked the project and managed to forward the token, hope it would help you

3 Likes
24

@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
25

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.

3 Likes
26

We’ve added a section in our best practices docs explaining why the Apollo MCP server doesn’t support token passthrough:

27

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.