Hi! Are there any plans to support custom authorization headers in Apollo MCP Server soon? Would be great to know if it’s on the near roadmap.
is there any indirect way to support custom auth headers for now?
1 Like
While I had no success (so far) including an Authorization header via MCP Inspector, I was able to successfully make authenticated calls to our internal supergraph via the MCP server by setting the header on the docker container startup. Not the perfect solution for our use case, but if you are using an API key for a service account, it may suffice.
docker run --rm -p 5000:5000 \
-v "$(PWD)/my-schema.graphql" \
ghcr.io/apollographql/apollo-mcp-server:v0.3.0 \
--introspection \
--schema /data/supergraph.graphql \
--log debug \
--header "Authorization: Bearer "$(TOKEN) \
--endpoint https://my-supergraph/graphql
Thank you! But my application is multi-tenant and token-based, so I need to send different tokens depending on the tenant
Hey @Maximiliano_Ozernick I am the product manager for our MCP Server. MCP Auth is top of mind and we are looking into it now. I would love to hear about your project, let me know if you are open to sharing it and we can set something up. Same for you @rob-fusco!
In short, our hope was to include an bearer token in the Authorization header when making the request to the MCP server and having it be passed along to the Apollo supergraph. Via debugging, we can see the header being received by the MCP server, but when making the request to supergraph the header is not present.
We are running the MCP server in SSE mode (in Streamable mode, we do not observe headers in the MCP server logs). We are using Python and the LangChain MCP adapter to connect to the Apollo MCP server and this successfully sends the header to the MCP server as we can observe it in the debug logs of rmcp (sse_servers.rs line 70).
We are literally working through this today as we speak, so details are evolving. Apologies for any gaps.
Hi , @rob-fusco when running the SSE server
like this, is there any paths to the SSE endpoint. i mean /sse. because using mcp SSEserverparams , i cant connect to the endpoint directly
Hi @kevin_chu,
Thank you for the reply.
We have an Apollo GraphQL endpoint that can accept either a custom token we generate or a JWT, both sent via the Authorization header.
The token includes the necessary data to authenticate and identify the user.
As long as we can pass the headers through to the endpoint, we should be all set.
Do you have an estimate for when this functionality could be available?
Thank you!
2 Likes
The MCP specification doesn’t allow for this kind of token pass-through. Tokens must be validated by the MCP server, and tokens sent by the MCP client can only come from the authorization server associated with the MCP server.
Proper auth handling based on the MCP spec is on our roadmap and is currently in the design phase.
Thanks for the link, still getting up to speed on all the MCP specs. Lots of reading lately.
We use okta as an OAuth authorization server, so we are willing to follow all the specs as written. I think our main requirement is to have the server backing the supergraph be responsible for authorization of data access. User A can access user A’s data, but not user B’s data of the same resource. So as long as we can have a token that identifies the request to supergraph as attributable as the end user (and not some mcp server super powered service account) we would be good. Essentially we expect our LLMs to be acting on behalf of some end user who has access to a subset of data available via our supergraph.
Therefore we are super interested in dates and priority of auth handling based on MCP spec. I suspect you don’t have a set date if you are still in design, but any crumbs would be appreciated so we can do our planning.
1 Like
We utilize MCP on the server side and have been using environment variables for injecting auth tokens into the MCP server scope. It would be great if the Apollo MCP server could support something similar, essentially look for something like AUTH_BEARER_TOKEN in the environment, then forward this as an authorization header to the GraphQL endpoints.
The MCP server has a --header option that allows you to specify static header values to be sent the GraphQL request. You should be able to use an environment variable to set that option when starting the server.
@kevin_chu passing the Authorization request header from MCP server to the GraphQL server is a feature that I would plus one. Our use case matches what was described by @rob-fusco
An alternative would be if Rhai scripting support was added to MCP server and the script could pass the header. This is also how Apollo Router allowed custom implementations before they were available directly in the Router implementation.
@kevin_chu it look like the Apollo Rover project has support for the MCP server, but not Apollo Router. The high level use case is Apollo MCP → Apollo Router → NodeJS Apollo Server to support LLM tools which can query Federated GraphQL. The access control is provided by the Apollo Server which is currently forwarded from Apollo Router. Apollo MCP would just be another step in the chain.
Maybe this would also work as part of Apollo Router and most of the other features could be inherited from the Router?
it look like the Apollo Rover project has support for the MCP server, but not Apollo Router.
I am not sure what you mean by Rover has no support for Apollo Router, you can indeed start a locally running router via Rover. See The Rover dev Command - Apollo GraphQL Docs
We’re working on Auth for MCP, will have more updates soon.
Thanks for you answers!
It’s still unclear how you plan to handle multi-tenant applications without allowing the endpoint to read and process the authentication header.
We have several GraphQL APIs that rely directly on the authentication header to identify the customer. Simply forwarding the token using the MCP authentication header would solve this for us.
If that’s not currently supported, how do you plan to support this feature in the near future?
Thanks.
(post deleted by author)
BTW, wundergraph supports it
@Maximiliano_Ozernick Does it not require us to use Cosmo?
i did not tested it. but look like you have to migrate from apollo to cosmo