Auth metadata discovery: fallback URL built on resource host instead of authorization-server host
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 74/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
- Domain
- authentication
Research direction
Locate the AS-metadata fallback path containing new URL('/.well-known/' + type, resourceUrl) and trace how authorizationServerUrl is available there. Reproduce the differing-host case from the issue, then verify that the fallback requests the authorization-server host and no longer follows unrelated metadata; add or update coverage if the surrounding tests provide a suitable place.
Written by the indexing model from the issue text.
Description
Bug Description
When the well-known fallback DOES happen, the root well-known URL is built on the wrong base: the resource-server origin is used instead of the authorization-server issuer URL. When the AS lives on a different host than the resource, the fallback fetches an unrelated metadata document.
Steps to Reproduce
Repro (Superhuman): resource https://docs.superhuman.com/apis/mcp
- Resource metadata at
https://docs.superhuman.com/.well-known/oauth-protected-resource/apis/mcpcorrectly listsauthorization_servers: ["https://id.superhuman.com"]. - But the AS-metadata fallback fetches
https://docs.superhuman.com/.well-known/oauth-authorization-server(resource host) instead of theid.superhuman.comequivalent. - That document is for a DIFFERENT service (issuer
https://tokens.grammarly.com), so the client sends users to tokens.grammarly.com's authorize endpoint with a client registered at id.superhuman.com → 403 on the consent page.
Expected Behavior
The fallback should stay on the authorization-server host (https://id.superhuman.com/.well-known/oauth-authorization-server, which returns 200).
Actual Behavior
The fallback URL is constructed as new URL('/.well-known/' + type, resourceUrl) instead of using the authorizationServerUrl base, so it fetches another service's metadata document.
Environment
- Discovered via mcp-hub 4.2.1 (npm, node 24, macOS) in front of remote OAuth MCP servers.
- Local workaround confirmed: switching the fallback base from the resource URL to the authorization-server URL fixes it.
Related
Possibly related to #1716 (wrong redirect URL when AS discovery fails for non-root paths) — this is the fallback-URL construction itself picking the wrong host.
- Dominant language
- TypeScript
- Stars
- 13.4k
- Forks
- 2.2k
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 3
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from modelcontextprotocol/typescript-sdk
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
modelcontextprotocol/typescript-sdk#2783 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
modelcontextprotocol/typescript-sdk#2766 · 1 comment ·
-
Difficulty 2/5 1-2 days Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
modelcontextprotocol/typescript-sdk#2742 · 2 comments ·
All issues in modelcontextprotocol/typescript-sdk
Similar issues
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100