Not able to customize the url '.well-known/oauth-protected-resource' behind AKS/nginx ingress

[sanjaydebnath]

Describe the bug
When we enable OAuth (using Entra) for the MCP server it produces the well known resource url through '/.well-known/oauth-protected-resource'.

.AddMcp(options =>
{
    var metadata = new ModelContextProtocol.Authentication.ProtectedResourceMetadata()
    {
        Resource = new Uri(serverAddress + "api/mcp"),
        AuthorizationServers = { new Uri($"{instance}/{tenantId}/v2.0") },
        ScopesSupported = [$"{apiAppName}/Mcp.Access"],
    };

    options.ResourceMetadata = metadata;
});
...
...
app.MapMcp("/api/mcp").RequireAuthorization();

Now when we deploy this behind an ingress controller with path redirects, the MCP client doesn't have a way to know the modified resource url that it needs to connect.

E.g. if I deploy the server from this base route 'https://abc.azure.com/sanjayd' with ingress redirects, we can ideally reach the mcp server at 'https://abc.azure.com/sanjayd/api/mcp', and that will throw 401. But all clients including VS Code etc. now tries to connect to 'https://abc.azure.com/.well-known/oauth-protected-resource' to download the metadata. Ideally there should be a way to mention the base route for metadata while using ingress.

1st call from client: POST https://abc.azure.com/sanjayd/api/mcp -> returns 401 with 'www-authenticate' header like 'Bearer realm="McpAuth", resource_metadata="http://10.10.1.40/.well-known/oauth-protected-resource"'

2nd call from client: GET https://abc.azure.com/.well-known/oauth-protected-resource -> missing the 'sanjayd' part.

This works locally though as there is no ingress/re-route.

Any help is appreciated on how this will work with ingress.

Below are from a web client

[QinjianZheng]

I have the exactly same problem, I found out there is a parameter when configure AddMcp: options.ResourceMetadataUri which would be returned with 401 response in WWW-Authenticate header. However, by providing the parameter, .well-known/oauth-protected-resource endpoint returns 404 for some reason, which is blocking me : <

[halter73]

Thanks for filing #654 @QinjianZheng. This does appear to be related. I'm just leaving this comment to cross-reference to two issues.

[QinjianZheng]

Thanks for filing #654 @QinjianZheng. This does appear to be related. I'm just leaving this comment to cross-reference to two issues.

Thanks, I came across this issue and dug a bit further, and wanted to provide more details but didn’t want to hijack this issue, or maybe I should provide more details here. First time raising a bug here haha

[nick-coremont]

I had a similar looking problem when running locally with docker-compose. I ran container for nginx which load-balanced requests to my two running MCP servers. the WWW-Authenticate header was not constructed correctly due to the McpAuthenticationHandler.HandleChallengeAsync usage of GetAbsoluteResourceMetadataUri.

The GetAbsoluteResourceMetadataUri() method is using GetBaseUrl() which constructs the URL from the current HTTP request's Request.Scheme, Request.Host, and Request.PathBase.

When a request comes through nginx, the request that reaches the MCP server containers has:

Request.Scheme = "http"
Request.Host = "localhost" (without port, since nginx is forwarding internally)
Request.PathBase = ""

By updating the nginx.conf to add:

            proxy_set_header Host $host:$server_port;
            proxy_set_header X-Forwarded-Host $host:$server_port;
            proxy_set_header X-Forwarded-Port $server_port;

The correct URL was constructed for the header.

[blasotta]

While i agree that it should be possible to define an absolute PRM Uri, which is currently bugged, it still should be possible to use the SDK in an application behind an ingress controller as of now, without adjustment to the SDK itself.

As @nick-coremont has pointed out you need to ensure that your proxy adds the X-Forwarded-Host and X-Forwarded-Proto to the forwarded request (many do that by default) and also that your server actually uses these forwarded headers by including the ForwardedHeadersMiddleware to your application, see my comment on how to do this in issue #654 for reference. The www-authenticate header will then be built with the forwarded protocol and host, instead of the local host.