f8a46726b7
An RFC 9728 `WWW-Authenticate: Bearer resource_metadata="…"` challenge was parsed and then dropped by the normalized `AuthChallenge`, so every challenge-driven `mcpAuth()` call ran discovery without it and probed locations derived from the MCP server URL instead. OAuth failed outright against any server whose metadata document lives off the well-known path. The SDK handles this correctly inside its own transports, but the Inspector never reaches that path — it intercepts the 401 and drives `auth()` itself to capture the authorization URL and run the step-up scope union. Carry the advertised URL on `AuthChallenge` as a string (it crosses the web client's remote-backend boundary as JSON), convert it at the OAuth boundary, and pass it to the standard challenge leg, the forced step-up leg, and CIMD pre-registration — which runs before `auth()` and did its own discovery. A malformed value is ignored rather than surfaced, matching the SDK's parser. The callback leg needs nothing: SDK `auth()` persists the URL in its discovery state. Adds an `oauth.resourceMetadataPath` test-server mode that moves the document off the well-known path entirely, so the integration test proves discovery genuinely fails without the fix. Closes #2071 Signed-off-by: cliffhall <cliff@futurescale.com>
19 lines
401 B
JSON
19 lines
401 B
JSON
{
|
|
"serverInfo": {
|
|
"name": "oauth-custom-resource-metadata",
|
|
"version": "1.0.0"
|
|
},
|
|
"tools": [{ "preset": "echo" }],
|
|
"oauth": {
|
|
"enabled": true,
|
|
"mode": "combined",
|
|
"requireAuth": true,
|
|
"resourceMetadataPath": "/custom/protected-resource",
|
|
"scopesSupported": ["mcp"],
|
|
"supportDCR": true
|
|
},
|
|
"transport": {
|
|
"type": "streamable-http",
|
|
"port": 8082
|
|
}
|
|
}
|