[BUG] Remote: OAuth protected resource metadata has wrong protocol in ACA

[vukelich]

Describe the bug

The HTTP 401 challenge for unauthenticated requests uses the incoming request protocol for crafting the resource_metadata value in the WWWAuthenticate as in

mcp/core/Azure.Mcp.Core/src/Areas/Server/Commands/ServiceStartCommand.cs

Line 412 in 493f8de

string resourceMetadataUrl = $"{request.Scheme}://{request.Host}/.well-known/oauth-protected-resource";

The protocol for the URL is fine when the MCP server is being directly connected by the client, such as local development or App Service. ACA container apps would see the http protocol because that's the default behavior for the ACA environment's reverse proxy.

Expected behavior

resource_metadata value in the WWWAuthenticate should match the original client request, including both protocol and host name.

Actual behavior

On ACA apps, resource_metadata value in the WWWAuthenticate matches the correct host name but the protocol is http. This results in clients like VS Code calling a URL that fails.

Reproduction Steps

asdf

Steven's maintainer note 2026-02-05: Ah, yes, "asdf". How dare you, past Steven.

Environment

No response

[anuchandy]

Status: Steven (or someone) needs to finish this work (draft). It’s currently broken when "VS Code" connects to an MCP server running on ACA, due to ACA’s default internal ingress being HTTP. This does not impact App Service, since it uses HTTPS end-to-end by default.

[anuchandy]

I discussed this with Vinay and he'll take it on. Since we can reproduce this issue when VS Code connects to the Azure MCP server on ACA, our validation plan is to build the Docker image with the fix locally, push it to ACA, and test the VS Code connection. We can use this https://github.com/anuchandy/azmcp-remote-dev-deploy/tree/main setup for validation.