OAuth discovery fails against Keycloak: client only tries RFC 8414 canonical well-known path, doesn't fall back to realm-first / OIDC discovery

[Nubilly]

Which version line?

v2 — current (@modelcontextprotocol/inspector@latest)

Which client?

Web

Inspector version

2.5.0

Node version

22.19.0

Operating system (and browser, for the web client)

No response

Transport

Streamable HTTP

MCP server under inspection

• MCP Inspector version: 2.5.0
• MCP server: ASP.NET Core, ModelContextProtocol.AspNetCore, Streamable HTTP transport
• Authorization server: Keycloak 26.0
  npx -y @modelcontextprotocol/inspector@2.5.0 --server mcp-server

Steps to reproduce

1. Point Inspector at an MCP server (Streamable HTTP) that requires OAuth and serves RFC 9728 protected-resource
   metadata correctly.
2. Server responds 401 with WWW-Authenticate: Bearer resource_metadata="<server>/.well-known/oauth-protected-resource/mcp".
3. Inspector fetches that URL successfully and reads authorization_servers: ["https://keycloak:9090/realms/tenant"].
4. Inspector then requests https://keycloak:9090/.well-known/oauth-authorization-server/realms/tenant → 404.
5. The OAuth flow terminates here with no further attempt.

Expected behavior

Per RFC 8414 §3.1 and common client fallback practice, when the plain-OAuth well-known metadata request fails, the
client should also try:

• The same well-known name in "simple append" form:
  https://keycloak:9090/realms/tenant/.well-known/oauth-authorization-server (confirmed working, returns 200 with
  valid metadata — see evidence below)
• OIDC discovery as a fallback: https://keycloak:9090/realms/tenant/.well-known/openid-configuration (also
  confirmed working)

Actual behavior

Only the RFC 8414 canonical form (.well-known/oauth-authorization-server inserted before the issuer path) is
attempted. On 404, the flow dies with no fallback, and the connection cannot be authenticated via Inspector's OAuth
button at all.

Logs, errors, or screenshots

$ curl -sk -i "https://keycloak:9090/.well-known/oauth-authorization-server/realms/tenant"
HTTP/1.1 404 Not Found

$ curl -sk -i "https://keycloak:9090/realms/tenant/.well-known/oauth-authorization-server"
HTTP/1.1 200 OK
{"issuer":"https://keycloak:9090/realms/tenant", ...valid RFC 8414 metadata...}

$ curl -sk -i "https://keycloak:9090/realms/tenant/.well-known/openid-configuration"
HTTP/1.1 200 OK
{"issuer":"https://keycloak:9090/realms/tenant", ...valid OIDC metadata...}

Already prototyped a fix?

No response

Before you submit

• I searched existing issues and this is not a duplicate.
• This is not a security vulnerability report (those go through the private advisory process).

[kocaemre]

I prototyped a narrow fix for this on a signed branch, following the repo's maintainer-opened PR flow rather than opening a PR directly.

Branch/compare:

• kocaemre:v2/fix/2296-keycloak-realm-discovery
• https://github.com/modelcontextprotocol/inspector/compare/v2/main...kocaemre:inspector:v2/fix/2296-keycloak-realm-discovery?expand=1
• commit: b2d90f7dc6274e2d3a258c0346e35ca74c0c0628

What changed:

• keeps the existing SDK canonical RFC 8414 request as the first attempt;
• when that canonical request fails with a discovery-continuable status, probes the Keycloak-style realm-first RFC 8414 path first, e.g. /realms/tenant/.well-known/oauth-authorization-server;
• preserves the existing OIDC fallback behavior after that;
• adds a regression proving an RFC 8414 document served from the realm-first path is substituted back into discovery before any OIDC probes.

Validation I ran locally:

cd clients/web && npm run test -- --run src/test/core/auth/oidcDiscoveryCompat.test.ts
# PASS: 1 file, 31 tests

npm exec -- eslint core/auth/oidcDiscoveryCompat.ts clients/web/src/test/core/auth/oidcDiscoveryCompat.test.ts --max-warnings 0
# PASS

cd clients/web && npm run format:check -- src/test/core/auth/oidcDiscoveryCompat.test.ts && cd ../.. && npm run format:check:core
# PASS

cd clients/web && npm run build
# PASS: tsc -b, vite build, tsup runner build

git diff --check upstream/v2/main..HEAD
# PASS

I also attempted the repo's full pre-push gate:

npm run format && npm run local:gate; echo EXIT=$?
# FAILED: web eslint hit Node's default heap limit after ~2 minutes, EXIT=134

NODE_OPTIONS=--max-old-space-size=4096 npm run local:gate; echo EXIT=$?
# BLOCKED: exceeded this cron job's 600s command timeout while in the broader web unit suite

Before the timeout, the second run had already passed the root verify steps and was progressing through validate:web; the focused test/lint/format/build checks above are green for the touched code path.

[Nubilly]

turns out this was a tls issue, the inspector just stopped with "failed to fetch" on a URL that didn't exist, so i assumed something was wrong. closing this. might be nice to have the tls error displayed instead of "failed to fetch"

[anythingoah]

Is this blocking a live integration for you, or did you catch it while testing against Keycloak specifically? Curious if other OAuth providers you've tried handled discovery differently.

[Nubilly]

nope, just while testing, was looking for something to test end-to-end a new mcp server and came across this. wrapping my head around this has been an adventure so far. the issues i've been running into has mainly been miss-configurations and an old keycloak version. i have the flow working now. its just the server not playing nicely now.