OAuth: Resource metadata URL lost after redirect, causing token exchange to fail

Problem

When using OAuth in browser environments, the resource metadata URL discovered during the initial WWW-Authenticate challenge is lost after the redirect to the authorization server and back. This causes the token exchange to fail because the SDK tries to re-probe for the Protected Resource Metadata (PRM) and can't find the token endpoint.

Current Behavior

1. Client makes request, gets 401 with WWW-Authenticate header containing resource metadata URL
2. SDK extracts PRM URL and fetches authorization server metadata
3. User is redirected to authorization server
4. After redirect back, the SDK needs to exchange the auth code for a token
5. Problem: The SDK tries to fetch PRM again but the original resource metadata URL was lost during the redirect
6. Token exchange fails

Expected Behavior

The SDK should retain knowledge of:

• The resource metadata URL from the initial WWW-Authenticate header
• The authorization server metadata (so it can go straight to the token endpoint)

This would avoid needing to re-probe for the token endpoint after the redirect.

Possible Solutions

1. SDK-level fix: Cache both the PRM URL and the authorization server metadata so token exchange can proceed without re-discovery

2. OAuth provider callback: Add a new method to the OAuth provider interface that gets called with the resource metadata, allowing implementations to persist it (e.g., to sessionStorage)

3. Popup/new tab pattern: Open the auth URL in a popup/new tab and use window.opener.postMessage to communicate back, keeping the original page open with its state intact

4. Application-level workaround: Applications can manually capture and store the resourceMetadataUrl before redirect and retrieve it afterward (e.g., in localStorage/sessionStorage)

Context

This is particularly problematic in browser environments where navigation away from the page loses the transport instance's internal state. The resource metadata URL is currently extracted within the transport instance, so applications don't have direct access to persist it.

Related

• Inspector issue: needs to either implement a workaround or wait for SDK fix
• Affects any browser-based MCP client using OAuth with redirects

Start by tracing the transport instance's PRM URL extraction through the browser redirect and token exchange flow described in the issue. Compare the SDK-level cache and OAuth provider callback approaches; done means the resource metadata and authorization server metadata survive navigation and the token exchange succeeds without re-probing.