claude.ai connector ignores RFC 9728 protected-resource metadata — cannot connect to Splunk Cloud MCP Server (external authorization server)

### MCP server URL or name

Splunk Cloud Platform — "MCP Server for Splunk platform" app v1.2.x (endpoint: https://.splunkcloud.com/en-US/splunkd/__raw/services/mcp, hostname redacted)

### How are you connecting to this server?

From a custom connector URL I entered manually

### Where does the issue occur?

When pressing the Connect button

### When did you last reproduce this?

2026-08-10 14:05 CEST

### Browser and OS

Chrome 141 on Windows 11

### Describe the issue

The claude.ai custom connector cannot authenticate against Splunk Cloud Platform's MCP Server because the MCP endpoint and its OAuth authorization server are on different hosts. The connector ignores the `WWW-Authenticate: Bearer resource_metadata=…` challenge and the RFC 9728 protected-resource document, and redirects to `{mcp-origin}/authorize` instead of the advertised `authorization_endpoint`.

Splunk Cloud is a managed product, so the workaround suggested in #82 (proxy routes at the MCP server root) is not available to customers.

**The server side is fully spec-compliant — verified with curl:**

1. Unauthenticated POST returns a correct challenge:

$ curl -i -X POST -H "Content-Type: application/json" \
https://.splunkcloud.com/en-US/splunkd/__raw/services/mcp

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://.splunkcloud.com/en-US/splunkd/__raw/services/.well-known/oauth-protected-resource"

{"jsonrpc":"2.0","id":null,"error":{"code":-32600,"message":"Authentication failed: missing or invalid token"}}

2. That metadata URL resolves and names the external authorization server:

HTTP/1.1 200 OK
{"resource":"https://.splunkcloud.com/en-US/splunkd/__raw/services/mcp",
"authorization_servers":["https://.api.scs.splunk.com//sis/v1/rg/"]}

3. The authorization server publishes valid metadata at `{issuer}/.well-known/openid-configuration`:

HTTP/1.1 200 OK
{"issuer":"https://.api.scs.splunk.com//sis/v1/rg/",
"authorization_endpoint":".../oauth2/authorize",
"token_endpoint":".../oauth2/token",
"code_challenge_methods_supported":["S256","plain"],
"grant_types_supported":["authorization_code","refresh_token"],
"scopes_supported":["openid","email","groups","offline_access","fedtype"]}

**Actual behaviour:** pressing Connect redirects the browser to `https://.splunkcloud.com/en-US/authorize?...`, which returns HTTP 404. The path is `{mcp-origin}/authorize` — derived from the connector's server URL, not from the metadata. (`/en-US/` is Splunk Web's locale rewrite of `/authorize`.)

Repeated with an alternate MCP endpoint on port 8089; the redirect became `https://.splunkcloud.com:8089/authorize`, confirming the URL is built from the configured server URL in both cases.

Claude Code CLI connects successfully to the identical endpoint, so this appears specific to the web connector's discovery implementation.

### Error details

```shell
No error dialog was shown in Claude.ai. The browser was redirected out of claude.ai to a URL that 404s, so the failure surfaces as Splunk's own 404 page rather than a Claude error.

Redirect URL issued by Claude (values redacted):
https://.splunkcloud.com/en-US/authorize?response_type=code&client_id=&redirect_uri=https%3A%2F%2Fclaude.ai%2Fapi%2Fmcp%2Fauth_callback&code_challenge=&code_challenge_method=S256&state=

HTTP 404. Splunk request ID: 6a7535f94370af5aacbb60
Splunk's 404 page confirms the referrer: "This page was linked to from https://claude.ai/"

Second attempt with the port-8089 endpoint produced the same shape:
https://.splunkcloud.com:8089/authorize?response_type=code&client_id=&...
```

### Expected behavior

Per RFC 9728 and the current MCP authorization spec, the connector should:

1. Read the `WWW-Authenticate: Bearer resource_metadata="…"` header from the 401
2. Fetch that protected-resource document
3. Take the issuer from `authorization_servers`
4. Fetch that issuer's authorization-server metadata
5. Redirect to the advertised `authorization_endpoint`:
https://.api.scs.splunk.com//sis/v1/rg//oauth2/authorize
6. Exchange the code at the corresponding `token_endpoint`

Instead, steps 1–4 appear to be skipped and the authorize URL is constructed as `{server-url-origin}/authorize`.

### Additional context

**Already-filed related issues** (both closed — filing fresh because this is a shipping vendor SaaS product where the documented workaround is impossible):

- #82 — "Claude.ai ignores authorization_endpoint and token_endpoint from OAuth metadata when MCP server uses external authorization server" (closed as not planned). Same root cause; that report was self-hosted, where proxy routes at the server root were a viable workaround. Splunk Cloud customers cannot add routes.
- #376 — "Custom connector AS-metadata discovery probes path-aware / OIDC well-known URLs that don't match authorization_servers issuer" (closed).

**Secondary: discovery should fall through on non-404 statuses.**

On this issuer the RFC 8414 locations do not return 404:

| URL | Status | Body |
|---|---|---|
| `https:///.well-known/oauth-authorization-server//sis/v1/rg/` | 400 | `tenant in host does not match tenant in path` |
| `{issuer}/.well-known/oauth-authorization-server` | 401 | `Authorization header is not Bearer.` |
| `{issuer}/.well-known/openid-configuration` | 200 | valid metadata |

Splunk's API gateway requires the tenant as the first path segment, so RFC 8414 path-insertion is structurally unservable on this platform. A discovery implementation that only advances to OIDC discovery on a 404 will still fail here even after the primary bug is fixed.

**Minor server-side note:** the `WWW-Authenticate` challenge appears only on POST. A GET to the MCP endpoint returns `405 Method Not Allowed` (`Allow: POST,OPTIONS`) with no challenge header. Since GET is a legal probe for MCP Streamable HTTP, a client probing that way learns nothing. Raised with Splunk separately.

**Impact:** any Splunk Cloud customer wanting Splunk MCP Server in claude.ai is blocked, with no customer-side workaround. Splunk documents `https:///api/mcp/auth_callback` as a supported hosted-client redirect URI, so both vendors expect this configuration to work.

Happy to supply unredacted traces privately if that helps reproduction.