OAuth discovery treats any /.well-known/openid-configuration response as full OIDC ( rejecting plain OAuth 2.0 authorization )

[justinhunt]

Which version line?

v2 — current (@modelcontextprotocol/inspector@latest)

Which client?

CLI

Inspector version

2.4.0

Node version

v22.22.0

Operating system (and browser, for the web client)

Linux (WSL2), kernel 6.18.33.2-microsoft-standard-WSL2, x86_64

Transport

Streamable HTTP

MCP server under inspection

https://misc.poodll.com/mod/minilesson/mcp.php — a plain OAuth 2.0 authorization server (no OIDC: no ID tokens, no jwks_uri, no sub claims). Resource lives under a path, not the domain root.

Steps to reproduce

1. Run:
   npx @modelcontextprotocol/inspector@2.4.0 --cli
   --server-url "https://misc.poodll.com/mod/minilesson/mcp.php"
   --transport http --method tools/list --connect-timeout 15000
2. No TTY: set MCP_AUTO_OPEN_ENABLED=true and re-run.
3. buildDiscoveryUrls() (client/dist/index.mjs:1016) builds three candidate URLs; the one that resolves is the append form ${pathname}/.well-known/openid-configuration, tagged type: "oidc" purely from its filename.
4. discoverAuthorizationServerMetadata() (client/dist/index.mjs:1088) picks the validation schema from that tag alone: type === "oauth" ? OAuthMetadataSchema : OpenIdProviderDiscoveryMetadataSchema.
5. Our plain-OAuth response gets validated against OpenIdProviderDiscoveryMetadataSchema, which requires jwks_uri, subject_types_supported, id_token_signing_alg_values_supported (core/dist/auth-CUe6YdwF.mjs:1541–1554).
6. Zod parse throws, connection fails.

Expected behavior

Our plain OAuth 2.0 authorization server (no OIDC) publishes its metadata at /.well-known/openid-configuration. Discovery should accept that as valid RFC 8414 metadata.

Actual behavior

Discovery fails when the resolved metadata URL ends in "openid-configuration". Even though the response itself makes no OIDC claim. The schema is evaluated as OIDC. And since the actual schemea is OAuth, not OIDC, it fails

Logs, errors, or screenshots

{"error":{"code":"error","message":"[
{"expected":"string","code":"invalid_type","path":["jwks_uri"],"message":"Invalid input: expected string, received undefined"},
{"expected":"array","code":"invalid_type","path":["subject_types_supported"],"message":"Invalid input: expected array, received undefined"},
{"expected":"array","code":"invalid_type","path":["id_token_signing_alg_values_supported"],"message":"Invalid input: expected array, received undefined"}
]"}}

Already prototyped a fix?

Don't key the schema on which well-known filename resolved. Instead either:

1. try OAuthMetadataSchema first and only fall back to OpenIdProviderDiscoveryMetadataSchema on failure, or
2. make jwks_uri, subject_types_supported, id_token_signing_alg_values_supported optional in OpenIdProviderMetadataSchema (core/dist/auth-CUe6YdwF.mjs:1546,1553,1554), and just check for actual OIDC behavior (ID token requests, userinfo calls) if they are present

In our tests, we made the three fields optional in OpenIdProviderMetadataSchema. With that change, discovery completes, /authorize redirects correctly, and tools/list returns real results end to end against the same server.

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).

[ump45nose]

I independently reproduced this with the Inspector v2 lockfile (@modelcontextprotocol/client@2.0.0) and an injected fetchFn:

• the RFC 8414 and inserted-path discovery URLs returned 404;
• the appended .../tenant/.well-known/openid-configuration URL returned 200 with valid OAuth AS metadata but no OIDC-only fields;
• discoverAuthorizationServerMetadata() threw the same ZodError for jwks_uri, subject_types_supported, and id_token_signing_alg_values_supported.

This looks like a TypeScript SDK parsing bug rather than an Inspector URL-candidate bug. RFC 8414 explicitly says openid-configuration can identify general OAuth metadata, and its jwks_uri is optional. The narrow regression test should therefore live beside the SDK discovery tests: an OIDC-named candidate returning RFC 8414 metadata must succeed while issuer equality validation remains enforced.

I also checked the current schemas locally: OAuthMetadataSchema accepts the plain response, and because it is a loose object it accepts a complete OIDC response without dropping jwks_uri, subject_types_supported, or id_token_signing_alg_values_supported. That makes an OAuth-schema fallback at the discovery boundary less invasive than weakening the OIDC schema itself.

Exact AI-assisted prototype prompt:

Using only the Inspector v2 lockfile and installed @modelcontextprotocol/client@2.0.0, reproduce issue #2172 with an injected fetch function. Return 404 for the RFC 8414 and inserted-path candidates, then return plain RFC 8414 OAuth metadata from the appended openid-configuration candidate. Compare OAuthMetadataSchema with OpenIdProviderDiscoveryMetadataSchema, verify the behavior against RFC 8414 Sections 2, 3, and 5, preserve issuer validation, and do not publish or push anything.

Verification performed: dependency install with scripts disabled; direct SDK reproduction; direct schema comparison; Inspector working tree remained clean.

AI assistance disclosure: AI was used to discover this opportunity and draft the change or text. I reviewed the reasoning, diff, and verification results before submission.

[cliffhall]

Triage: Priority Medium (total 8)

• Severity 4 — discovery fails outright against a plain OAuth 2.0 AS that publishes RFC 8414 metadata at /.well-known/openid-configuration, so connecting to that server is impossible (no partial workaround from inside the Inspector)
• Urgency 3 — wanted this milestone; reproduced on the published 2.4.0, but scoped to one class of authorization server and nothing else is blocked on it
• Bonuses: +1 bug label

Board: #28, Status Incoming (awaiting maintainer review — no milestone yet).

Note for whoever picks this up: per the reproduction in the comment above, the schema selection happens in @modelcontextprotocol/client (discoverAuthorizationServerMetadata keying the validation schema off the resolved well-known filename), not in Inspector code — so the fix may belong upstream in the TypeScript SDK, with the Inspector side limited to a version bump.

[cliffhall]

Root-caused upstream and filed as modelcontextprotocol/typescript-sdk#2733 — discoverAuthorizationServerMetadata selects its validation schema from the well-known filename that resolved rather than from the document, so any body served at openid-configuration is required to satisfy OpenID Connect Discovery 1.0. RFC 8414 §5 permits that filename for general OAuth metadata, so this server is conforming. The parse also throws instead of continuing the candidate loop, which is why discovery aborts rather than falling through.

Inspector-side workaround in #2184, which does not wait on the SDK: when the RFC 8414 candidate 4xx's, the Inspector probes the OIDC candidates and — if one returns a document that satisfies OAuthMetadataSchema but fails the OIDC schema — hands that document back as the RFC 8414 response, so the SDK validates it under the right schema. Nothing is fabricated (no synthetic jwks_uri), issuer validation is untouched, and the Network tab still shows the real 404 and the real probe.

test-servers/configs/oauth-rfc8414-at-oidc-path-http.json reproduces your server's shape locally.