We’ve been running our MCP server pointed at our own schema, built entirely outside of Apollo. The requirements are now unclear: following the docs, do we need to publish our graph to Apollo now? Or just create a pseudo-account account to retrieve YOUR_APOLLO_KEY and YOUR_APOLLO_GRAPH_REF, even though the contents of the graph are empty? To support Authentication, do we need to migrate?
Additionally, are there any plans to support OAuth 2.0? Given 2.1 is still ‘in progress’, many libraries and frameworks have yet to support it. For example, the ruby ecosystem. In our case, our entire authentication infrastructure is locked out even if we were to sign up, due to everything being built around 2.0.
In the absence of ^, a sort of compromise PR is here – which is safe as it just passes through mcp-session-id that proxies can use; this header originates from remote-mcp and is invoked from MCP clients.
Worst case, if there’s no plan to support OAuth 2.0, it would be great if y’all exposed some kind of dangerously_allow_header_passthrough option, and defer to developer responsibility. Otherwise many things are simply not workable for much of the community, and there are many cases where header passthrough like this is acceptable.
Hi @chriss , you do not need to publish your graph to Apollo to use the MCP server with authentication. The server still supports local schema sources via the schema.source: local configuration option. You can run it entirely with your won schema files. We used GraphOS Router in the example in the guide docs because it supports the JWT authentication. This combination makes the whole authentication flow more realistic.
@chriss As to OAuth 2.0 support, Apollo MCP Server only supports OAuth 2.1. The authentication is specifically designed around the protected resource specification of OAuth 2.1. I’m not sure if using OAuth 2.0 would even comply with the MCP Authorization specification:
The team is considering header forwarding support, though we haven’t decided on the implementation approach yet. Your input on which approach would work best for your proxy setup would be valuable to that discussion. Thank you!
Technically speaking, as long as Apollo MCP Server forwards along mcp-session-id from mcp-remote (assigned when a user sets up their MCP client and calls the server), then a proxy server can be setup and userland can implement their own OAuth implementations, forward headers, and more, without Apollo needing to allow for header pass-through, and keeping things locked down. It would help greatly with flexibility within different environments and general observability if this header were passed through.
That said, also providing first-class support for headers would make a lot of folks happy.
Thanks for this! For multi-tenant scenarios, how can upstream GQL APIs identify users? Given no headers/tokens are forwarded with tool execution requests.
@chriss We just reviewed and approved your PR. Thanks for the contribution! I’m going to release the change along with some other fixes in v0.7.1 soon.
Hi @glenn , Apollo MCP Server propagates validated tokens to upstream GraphQL APIs. You can access the bearer token from the Authorization header and decode it on your server to extract user claims.
I wanted to use the mcp for some specific use case. I set up everything properly I think but I’m getting trouble with audience where my jwt dont have it and the jwks library is blocking it.
i m using cognito, I would love some guidance here or help if possible.
Hi @Yan_Matagne, could you share why your JWT doesn’t include an aud cliam? Apollo MCP Server validates the audience to ensure the token was issued for the correct system. You should be able to set up Cognito to generate tokens with the audience.