OAuth Token Exchange Fails with Separate Authorization Servers #1450

Activity

1. waltmayf

   added

   bugSomething isn't workingSomething isn't working

   on Feb 2, 2026
2. sstklen commented on Feb 25, 2026

   

   sstklen

   on Feb 25, 2026

   More actions

   Hey! I ran into a similar pattern in our bug knowledge base and thought this might help.

   What's happening: In the MCP TypeScript SDK's OAuth flow, when the initial connection attempt receives a 401 response with a WWW-Authenticate header containing resource_metadata parameter, the SDK fails to parse and persist the resourceMetadataUrl from that header. When finishAuth() is later called (after user authorization), resourceMetadataUrl is undefined, causing the SDK to fall back to using the MCP server URL itself as the authorization server URL. This means token exchange requests (authorization code → access token) are sent to the MCP server instead of the actual authorization server (e.g., AWS Cognito, Auth0, Okta), resulting in 'Invalid api path' errors from the MCP server which doesn't handle token endpoints.

   What worked for us:

   The SDK's auth flow needs to extract the resource_metadata URL from the WWW-Authenticate header during the 401 challenge response and persist it so that finishAuth() can use it to discover the correct authorization server via RFC 9728 Protected Resource Metadata. Specifically: (1) parse the resource_metadata parameter from the WWW-Authenticate header in the 401 handler, (2) store it alongside other auth state (e.g., in the transport or auth provider), and (3) pass it to finishAuth() so the token exchange request goes to the correct authorization server endpoint discovered via the resource metadata document.

   Steps:

   1. In the 401 response handler (likely in StreamableHTTPClientTransport or the auth coordination layer), parse the WWW-Authenticate header to extract the resource_metadata parameter URL using a proper RFC 9110 challenge parser
   2. Store the extracted resourceMetadataUrl in the transport's auth state so it survives across the redirect-based OAuth flow (e.g., persist it alongside PKCE verifier, state parameter, etc.)
   3. In finishAuth(), pass the persisted resourceMetadataUrl to the authorization server discovery logic so it fetches /.well-known/oauth-protected-resource from the correct URL instead of falling back to the MCP server URL
   4. Add validation: if a resource_metadata parameter was present in the WWW-Authenticate header but cannot be fetched or parsed, fail with a clear error rather than silently falling back to the wrong server

   // In the 401 response handler (e.g., extractAuthInfo or similar):
   function extractResourceMetadataUrl(response: Response): string | undefined {
     const wwwAuth = response.headers.get('WWW-Authenticate');
     if (!wwwAuth) return undefined;
     // Parse resource_metadata parameter from Bearer challenge
     const match = wwwAuth.match(/resource_metadata="([^"]+)"/);
     return match?.[1];
   }
   
   // During 401 handling, persist the URL:
   const resourceMetadataUrl = extractResourceMetadataUrl(response);
   if (resourceMetadataUrl) {
     // Store in auth state that persists across the OAuth redirect flow
     this._resourceMetadataUrl = resourceMetadataUrl;
   }
   
   // In finishAuth(), use the persisted URL:
   async finishAuth(authorizationCode: string): Promise<void> {
     // Use stored resourceMetadataUrl instead of undefined
     const serverMetadata = await discoverOAuthProtectedResourceMetadata(
       this._resourceMetadataUrl ?? this._url // fallback only if no resource_metadata was advertised
     );
     // ... proceed with token exchange using correct authorization server
   }

   📊 We found 1 similar case in our knowledge base with the same pattern — this gives us medium confidence in this analysis.

   Hope this helps! Let me know if it doesn't match your case — happy to dig deeper. 🦞

   Disclosure: This analysis is from Confucius Debug, an AI-powered community KB for agent bugs. Please verify before applying.

   ---

   _{🦞 Confucius Debug — community knowledge base for AI agent bugs. Free to search via MCP.}
4. ghost added

   authIssues and PRs related to Authentication / OAuthIssues and PRs related to Authentication / OAuth

   on Apr 16, 2026
5. ghost added

   potentially closeBot recommends closing — needs maintainer reviewBot recommends closing — needs maintainer review

   on Apr 16, 2026