OAuth discovery does not fall back to well-known URI when 401 carries a non-Bearer WWW-Authenticate (e.g. Negotiate)

[caravin]

Describe the bug

StreamableHTTPClientTransport (TypeScript SDK 1.29.0) does not fall back to well-known protected-resource metadata discovery when a 401 response carries a non-Bearer WWW-Authenticate challenge such as Negotiate. The 401 is bubbled to the caller and the OAuth flow never starts, even though valid metadata is hosted at the spec-defined well-known URI.

The MCP authorization spec (Protected Resource Metadata Discovery Requirements) states:

MCP clients MUST support both discovery mechanisms and use the resource metadata URL from the parsed WWW-Authenticate headers when present; otherwise, they MUST fall back to constructing and requesting the well-known URIs in the order listed above.

"Otherwise" should include the case where WWW-Authenticate is present but does not advertise Bearer ... resource_metadata=.... Today the fallback only fires when the header is missing entirely (per PR #1045 / SEP-985).

To Reproduce

Steps to reproduce the behavior:

1. Stand up an MCP server that returns 401 with a non-Bearer challenge for unauthenticated requests, and hosts valid protected-resource metadata at the path-suffixed well-known URI:

   $ curl -i -X POST https://server/api/v1/help_python_skill/mcp \
       -H 'Content-Type: application/json' \
       -H 'Accept: application/json, text/event-stream' \
       -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"curl","version":"0"}}}'
   HTTP/1.1 401 Unauthorized
   www-authenticate: Negotiate
   content-type: text/plain
   
   Authentication required.
   
   $ curl -i 'https://server/.well-known/oauth-protected-resource/api/v1/help_python_skill/mcp'
   HTTP/1.1 200 OK
   content-type: application/json
   
   {"resource":"https://server/api/v1/help_python_skill/mcp",
    "authorization_servers":["https://server"],
    "scopes_supported":[".default"],
    "bearer_methods_supported":["header"]}
   

2. Connect to it from MCP Inspector (uses TS SDK 1.29.0):

   npx @modelcontextprotocol/inspector
   

3. Enter the server URL and pick streamable-http transport. Click Connect.

4. Observe the connection fails with a bare 401; no request is ever made to either well-known URL.

Expected behavior
On any 401 from the MCP endpoint, after parsing WWW-Authenticate:

1. If a Bearer challenge is present → use its resource_metadata URL.
2. Otherwise (header missing OR present with a non-Bearer scheme) → fall back to:
   • <origin>/.well-known/oauth-protected-resource<resource_path>
   • then <origin>/.well-known/oauth-protected-resource

Step 2 currently only fires when the header is missing entirely; it should also fire when the header advertises a non-Bearer scheme.

Logs
Inspector logs from a failing connection attempt:

[MCP] New StreamableHttp connection request
[MCP] Query parameters: {"url":"https://server/api/v1/help_python_skill/mcp","transportType":"streamable-http"}
[MCP] Created StreamableHttp client transport
[MCP] Client <-> Proxy  sessionId: 86af1624-e651-42ae-90a3-1fb0dade5bc5
[MCP] Error from MCP server: StreamableHTTPError: Streamable HTTP error: Error POSTing to endpoint: Authentication required.
[MCP]     at StreamableHTTPClientTransport.send (.../@modelcontextprotocol/sdk/dist/esm/client/streamableHttp.js:364:23)
[MCP]     at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
[MCP]   code: 401
[MCP] }

Additional context

• Affected file: src/client/streamableHttp.ts — the 401 handler in StreamableHTTPClientTransport.send (compiled at dist/esm/client/streamableHttp.js:364).
• Downgrading to @modelcontextprotocol/sdk@1.17.5 makes the connection work — discovery proceeds and OAuth completes — confirming this is a regression introduced in a later version's stricter handling of the 401 response.
• Workaround: pin @modelcontextprotocol/sdk to 1.17.5 via npm overrides in the consuming package.
• Real-world impact: any MCP server that (a) supports OAuth via the well-known URI mechanism and (b) sits behind middleware that emits a non-Bearer challenge (Kerberos/SPNEGO is common in enterprise environments) cannot be connected to from any client built on this SDK — including MCP Inspector.
• Environment:
  • @modelcontextprotocol/sdk: 1.29.0 (regression), 1.17.5 (works)
  • @modelcontextprotocol/inspector: 0.16.6 and 0.21.1 (both reproduce — same underlying SDK)
  • Node: v20.14.0
• Related: PR #1045 (SEP-985 fallback — handles only missing-header case), Issue #822, Issue #758.

[mcp-claude]

cannot reproduce the reported behavior on either v1.29.0 (bf1e022) or current main (7d7e62c). when StreamableHTTPClientTransport is given an authProvider, a 401 WWW-Authenticate: Negotiate response correctly fires well-known PRM discovery — the SDK calls /.well-known/oauth-protected-resource/mcp, then /.well-known/oauth-authorization-server, and invokes redirectToAuthorization. the same applies to the withOAuth middleware path.

the error the reporter saw — StreamableHTTPError: Error POSTing to endpoint: Authentication required. with code: 401 — is thrown when _authProvider is not set on the transport. in that case, v1.29.0 throws StreamableHTTPError for all 401s regardless of WWW-Authenticate scheme (missing / Negotiate / Bearer all behave identically).

to progress this, need a self-contained script that reproduces the failure. specifically:

• exact code that creates the transport and configures auth (does the inspector pass authProvider to StreamableHTTPClientTransport, or does it use a fetch wrapper?)
• inspector version + node version + exact SDK version showing the regression
• if using withOAuth middleware: is baseUrl passed, and does the well-known path match the PRM endpoint the server hosts?

repro script (both branches — passes on both)

// repro.ts — run with: npx tsx repro.ts
import http from 'node:http';
import { AddressInfo } from 'node:net';
import { StreamableHTTPClientTransport, extractWWWAuthenticateParams } from '@modelcontextprotocol/client';
import type { OAuthClientProvider, OAuthClientMetadata, OAuthClientInformationFull, OAuthTokens } from '@modelcontextprotocol/client';

const requestedUrls: string[] = [];

function createMockServer(): Promise<http.Server> {
  return new Promise((resolve) => {
    const server = http.createServer((req, res) => {
      requestedUrls.push(req.url ?? '');
      const url = req.url ?? '';
      if (url.startsWith('/.well-known/oauth-protected-resource')) {
        const port = (server.address() as AddressInfo).port;
        res.writeHead(200, { 'Content-Type': 'application/json' });
        res.end(JSON.stringify({ resource: `http://127.0.0.1:${port}/mcp`, authorization_servers: [`http://127.0.0.1:${port}`], scopes_supported: ['read'] }));
      } else if (url.startsWith('/.well-known/oauth-authorization-server')) {
        const port = (server.address() as AddressInfo).port;
        res.writeHead(200, { 'Content-Type': 'application/json' });
        res.end(JSON.stringify({ issuer: `http://127.0.0.1:${port}`, authorization_endpoint: `http://127.0.0.1:${port}/authorize`, token_endpoint: `http://127.0.0.1:${port}/token`, response_types_supported: ['code'], code_challenge_methods_supported: ['S256'] }));
      } else {
        res.writeHead(401, { 'WWW-Authenticate': 'Negotiate', 'Content-Type': 'text/plain' });
        res.end('Authentication required.');
      }
    });
    server.listen(0, '127.0.0.1', () => resolve(server));
  });
}

class MockOAuthProvider implements OAuthClientProvider {
  redirectUrl = 'http://localhost/callback';
  clientMetadata: OAuthClientMetadata = { client_name: 'test', redirect_uris: ['http://localhost/callback'] };
  async clientInformation(): Promise<OAuthClientInformationFull | undefined> { return { client_id: 'test-client', client_secret: 'secret', redirect_uris: ['http://localhost/callback'] }; }
  async tokens(): Promise<OAuthTokens | undefined> { return undefined; }
  async saveTokens(_: OAuthTokens): Promise<void> {}
  async redirectToAuthorization(url: URL): Promise<void> { console.log('redirectToAuthorization:', url.href); }
  async saveCodeVerifier(_: string): Promise<void> {}
  async codeVerifier(): Promise<string> { return 'verifier'; }
}

const server = await createMockServer();
const port = (server.address() as AddressInfo).port;
const transport = new StreamableHTTPClientTransport(new URL(`http://127.0.0.1:${port}/mcp`), { authProvider: new MockOAuthProvider() });
await transport.start();
await transport.send({ jsonrpc: '2.0', id: 1, method: 'initialize', params: { protocolVersion: '2025-06-18', capabilities: {}, clientInfo: { name: 'test', version: '0' } } }).catch(() => {});
await new Promise(r => setTimeout(r, 1000));
server.close();
console.log('URLs:', requestedUrls);
console.log('well-known fired:', requestedUrls.some(u => u.includes('/.well-known/oauth-protected-resource')));

command + output (main, 7d7e62c)

$ npx tsx repro.ts

=== Unit test: extractWWWAuthenticateParams ===
Negotiate result: {}
Bearer (no resource_metadata) result: {}

=== Integration test: 401 Negotiate → well-known discovery ===
Mock server: http://127.0.0.1:43791
[mock server] POST /mcp
[mock server] GET /.well-known/oauth-protected-resource/mcp
[mock server] GET /.well-known/oauth-authorization-server
[oauth provider] redirectToAuthorization called: http://127.0.0.1:43791/authorize?...&scope=read&resource=...
[transport] send() threw: UnauthorizedError: Unauthorized
URLs the SDK requested:
   /mcp
   /.well-known/oauth-protected-resource/mcp
   /.well-known/oauth-authorization-server
Well-known PRM discovery fired: true
OK: well-known PRM discovery fired correctly

command + output (v1.x, bf1e022 / 1.29.0)

$ npx tsx repro_v1x.ts

=== Unit test: extractWWWAuthenticateParams with Negotiate ===
extractWWWAuthenticateParams(Negotiate): {}

=== Integration test on v1.29.0 ===
Mock server: http://127.0.0.1:45109
[mock server] POST /mcp
[mock server] GET /.well-known/oauth-protected-resource/mcp
[mock server] GET /.well-known/oauth-authorization-server
[oauth provider] redirectToAuthorization called: http://127.0.0.1:45109/authorize?...&scope=read&resource=...
[transport] send() threw: UnauthorizedError: Unauthorized
URLs requested:
   /mcp
   /.well-known/oauth-protected-resource/mcp
   /.well-known/oauth-authorization-server
Well-known PRM discovery fired: true
OK: well-known discovery fired correctly on v1.29.0

no-authProvider test (confirms StreamableHTTPError is thrown for all header types equally)

=== No-authProvider 401 error type test ===
[no WWW-Authenticate]        error: StreamableHTTPError: Streamable HTTP error: Error POSTing to endpoint: Authentication required.
[WWW-Authenticate: Negotiate] error: StreamableHTTPError: Streamable HTTP error: Error POSTing to endpoint: Authentication required.
[WWW-Authenticate: Bearer]   error: StreamableHTTPError: Streamable HTTP error: Error POSTing to endpoint: Authentication required.

All 3 throw the same error type — consistent behavior

[caravin]

So I found this issue when testing with MCP Inspector. Just changing the typescript sdk fixed the issue for me leading me to think the issue is with the underlying sdk.
FWIW, In the inspector, I was able to manually do the quick Oauth and then connect. Also guided oauth and connect is also working. But only after token is generated, I was able to connect. If I simply do connect, it is trying to call the mcp server and after seeing 401, it is not reading the metadata URLs as per the protocol.
I thought this could be because my mcp server is not returning any challenges in its 401 response. I purposefully didnt add that because the protocl says it should be either that or support oauth metadata endpoints.
Also adding that older typescript sdk version was doing this. So something is wrong with the newer version only.
@felixweinberger, let me know if you need any other details here