WWW-Authenticate header does not contain a resource metadata params

[Emilio-Insight]

Describe the bug
I attempted to connect to the Atlassian Remote MCP Server (https://mcp.atlassian.com/v1/sse) using HttpClientTransport and successfully initialized the client. However, I’m encountering an issue that appears after the initial handshake. The 401-response header’s WWW-Authenticate field does not include the resource metadata parameters. This behavior is present with some other remote MCP servers that also no resource metadata.

I haven’t found a way to bypass this resource metadata check and proceed directly to the authorization server metadata discovery, even though this remote MCP server exposes it at:
https://mcp.atlassian.com/.well-known/oauth-authorization-server

To Reproduce
Steps to reproduce the behavior:

1. Create HttpTransportClient with OAuth.
2. Initialized the client.

Logs

Unhandled exception. ModelContextProtocol.McpException: The WWW-Authenticate header does not contain a resource_metadata parameter
   at ModelContextProtocol.Authentication.ClientOAuthProvider.ExtractProtectedResourceMetadata(HttpResponseMessage response, Uri serverUrl, CancellationToken cancellationToken)
   at ModelContextProtocol.Authentication.ClientOAuthProvider.PerformOAuthAuthorizationAsync(HttpResponseMessage response, CancellationToken cancellationToken)
   at ModelContextProtocol.Authentication.ClientOAuthProvider.HandleUnauthorizedResponseAsync(String scheme, HttpResponseMessage response, CancellationToken cancellationToken)
   at ModelContextProtocol.Authentication.AuthenticatingMcpHttpClient.HandleUnauthorizedResponseAsync(HttpRequestMessage originalRequest, JsonRpcMessage originalJsonRpcMessage, HttpResponseMessage response, CancellationToken cancellationToken)
   at ModelContextProtocol.Authentication.AuthenticatingMcpHttpClient.SendAsync(HttpRequestMessage request, JsonRpcMessage message, CancellationToken cancellationToken)
   at ModelContextProtocol.Client.StreamableHttpClientSessionTransport.SendHttpRequestAsync(JsonRpcMessage message, CancellationToken cancellationToken)
   at ModelContextProtocol.Client.AutoDetectingClientSessionTransport.InitializeAsync(JsonRpcMessage message, CancellationToken cancellationToken)
   at ModelContextProtocol.Client.AutoDetectingClientSessionTransport.InitializeAsync(JsonRpcMessage message, CancellationToken cancellationToken)
   at ModelContextProtocol.McpSessionHandler.SendRequestAsync(JsonRpcRequest request, CancellationToken cancellationToken)
   at ModelContextProtocol.McpSession.SendRequestAsync[TParameters,TResult](String method, TParameters parameters, JsonTypeInfo`1 parametersTypeInfo, JsonTypeInfo`1 resultTypeInfo, RequestId requestId, CancellationToken cancellationToken)
   at ModelContextProtocol.Client.McpClientImpl.ConnectAsync(CancellationToken cancellationToken)
   at ModelContextProtocol.Client.McpClientImpl.ConnectAsync(CancellationToken cancellationToken)
   at ModelContextProtocol.Client.McpClient.CreateAsync(IClientTransport clientTransport, McpClientOptions clientOptions, ILoggerFactory loggerFactory, CancellationToken cancellationToken)
   at ModelContextProtocol.Client.McpClient.CreateAsync(IClientTransport clientTransport, McpClientOptions clientOptions, ILoggerFactory loggerFactory, CancellationToken cancellationToken)

[martin-shields-bede]

I get the same issue on my end as well, can you let me know if you find some sort of workaround please?

[halter73]

#1054 and #1084 has significantly reworked how the client looks for well-known fallback endpoints. The changes in #1054 are already available at v0.5.0-preview.1 and the rest of the changes should become available when v0.5.0-preview.2 is released fully passing the conformance tests for the latest revision of the spec currently available in the https://github.com/modelcontextprotocol/conformance/ repo.

I don't have an Atlassian account, so I can't fully test the scenario, but I suspect that even with all these changes you still won't be able to connect, because it appears to be relying on the 2025-03-25 version of the Model Context Protocol auth spec that cohosts the MCP server and authorization endpoints on the same server. See #156 for more context.

I don't think we have any plans to ever support the old revision of the auth spec which was reworked to prevent potential security issues, but if we do support it, I could see doing it for the client only. @localden @mikekistler do you have any thoughts on this.