Auth metadata discovery: fallback URL built on resource host instead of authorization-server host

Aperta Adatta ai principianti
#2,784 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
74/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
authentication

Direzione di ricerca

Individua il percorso di fallback dei metadati AS che contiene new URL('/.well-known/' + type, resourceUrl) e traccia come authorizationServerUrl è disponibile al suo interno. Riproduci il caso dell’issue con host differenti, quindi verifica che il fallback richieda l’host del server di autorizzazione e non segua più metadati non correlati; aggiungi o aggiorna la coverage se i test circostanti offrono un punto adatto.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

  1. Resource metadata at https://docs.superhuman.com/.well-known/oauth-protected-resource/apis/mcp correctly lists authorization_servers: ["https://id.superhuman.com"].
  2. But the AS-metadata fallback fetches https://docs.superhuman.com/.well-known/oauth-authorization-server (resource host) instead of the id.superhuman.com equivalent.
  3. 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.

Lingua principale
TypeScript
Stelle
13.4k
Fork
2.2k
Merge medio
3g 12h
PR unite (30g)
3

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di modelcontextprotocol/typescript-sdk

Tutte le issue di modelcontextprotocol/typescript-sdk

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.