Web: concurrent OAuth flows to the same server overwrite each other's PKCE verifier (shared oauth.json keyed by server URL)

Start by reading clients/web/src/lib/remoteOAuthStorage.ts, core/auth/browser/storage.ts, and OAuthStorageBase.saveCodeVerifier to trace how OAuth state is stored and restored for /oauth/callback. Reproduce the overlap with two tabs using the provided steps, then inspect existing auth tests and add coverage for both flows completing with their own verifier. Done means concurrent flows no longer collide while the CLI/TUI stored-auth hand-off still works.

Which version line?

v2 — current (@modelcontextprotocol/inspector@latest)

Which client?

Web

Inspector version

2.11.0. The code involved is unchanged on v2/main as of 41018bea (2026-10-13).

Node version

v24.16.0 (npm i @modelcontextprotocol/[email protected], run with the same environment variables as the Docker image)

Operating system (and browser, for the web client)

macOS; Chrome (driven by Playwright)

Transport

Streamable HTTP

MCP server under inspection

An OAuth-protected streamable-HTTP server with Protected Resource Metadata → authorization server with Dynamic Client Registration, PKCE S256, token_endpoint_auth_method: none. Reproduced against a minimal mock authorization server and MCP server. The cause is in the Inspector's storage, so any server that uses PKCE triggers it.

Steps to reproduce

1. mcp-inspector --web (auth on, default settings).
2. Add an OAuth-protected streamable-HTTP server, or open the deep link /?serverUrl=<url>&transport=http&autoConnect=<token>.
3. Tab A: click Connect and stay on the authorization server's login page.
4. Tab B (same browser, same Inspector, same server): click Connect and complete the login.
5. Back in tab A: complete the login.

The same happens when several people use one deployed Inspector (Docker image behind a reverse proxy) and log in to the same server at about the same time.

Expected behavior

Each authorization flow completes with its own PKCE verifier, whatever other flows are in flight for the same server. Both tabs end up connected.

Actual behavior

Tab B connects. Tab A's token exchange is rejected by the authorization server (invalid_grant, PKCE verification failed). Tab A shows the "Re-authentication required … PKCE verification failed" banner, and the server card is in the error state. It offers a Re-authenticate button; reloading and logging in again connects.

Cause: the web client's per-server OAuth state (codeVerifier, discoveryState, DCR client info, tokens) is held in the backend's single oauth.json, through RemoteOAuthStorage (/api/storage/oauth), keyed by server URL only (ServerOAuthState.codeVerifier, written by OAuthStorageBase.saveCodeVerifier). Two overlapping flows for the same server share one verifier slot. Tab B's flow overwrites tab A's verifier, and B's successful exchange then clears it. When tab A's callback page hydrates the store, the verifier it needs is gone.

Measured (automated, one browser context per user, logins taking 300–2300 ms at the authorization server):

• 1 user, 2 tabs: tab A failed in each run (2/2) (authorization server log: authorize, token ok for B, then authorize, token rejected (PKCE) for A).
• 6 users opening the same deep link at about the same time: 1 of 6 connects.

Related: because the store is keyed by server URL and shared by every browser using the backend, one browser's DCR client and, with the default MCP_INSPECTOR_PERSIST_TOKENS=all, its acquired tokens are also served to every other browser on that Inspector. MCP_INSPECTOR_PERSIST_TOKENS=none avoids the token part but not the verifier collision.

Logs, errors, or screenshots

• Before (2.11.0), tab A after step 5: re-authentication banner reading "Authentication for … needs attention. PKCE verification failed", server card in error, two 400 POST /token requests in the Network panel.
• After (prototype below), tab A after step 5: server connected, "Authorization complete" notification.
• Failing token request: grant_type=authorization_code, code=<issued for flow A>, code_verifier=<not A's> → 400 {"error":"invalid_grant"}.
• GET /api/storage/oauth during the overlap shows one servers["<url>"].codeVerifier shared by both flows.

Already prototyped a fix?

Yes, as a local prototype to confirm the cause. It was built during a longer AI-assisted session rather than from one prompt, so below is a self-contained prompt that reproduces it, then a prompt for the fix we would actually suggest.

Prototype prompt (per-tab OAuth state; confirms the diagnosis):

In the v2 web client, OAuth state for a server (PKCE code verifier, discovery state, DCR client information, tokens) is persisted through RemoteOAuthStorage into the backend's shared oauth.json, keyed only by server URL. Two authorization flows for the same server that overlap in time (two tabs, or two users of one deployed Inspector) overwrite each other's codeVerifier, and the slower flow fails the token exchange with a PKCE error. Change the web client so this state is kept per browser tab: make getWebRemoteOAuthStorage() in clients/web/src/lib/remoteOAuthStorage.ts return the existing sessionStorage-backed getBrowserOAuthStorage() from core/auth/browser/storage.ts instead of a RemoteOAuthStorage. Keep the backend connect path unchanged (the browser already sends its auth state with /api/mcp/connect). Add a test where two flows for the same server URL are started before either completes, and assert that both exchanges use their own verifier and both connect.

Suggested fix prompt (keeps the shared store from #1548):

The web client's in-flight PKCE state must not be shared between concurrent authorization flows. Today OAuthStorageBase.saveCodeVerifier/getCodeVerifier/clearCodeVerifier key codeVerifier (and the discovery state saved with it) by server URL, in the shared remote store. Key the in-flight state by the auth session id that generateOAuthState() already puts in the OAuth state parameter (the 64-hex authId), or keep it in the initiating tab's sessionStorage, so the /oauth/callback completion reads the verifier for its own state. Only the outcome of a completed flow (client information, tokens) should be written to the shared server-URL-keyed store. Cover with tests: (1) two overlapping flows for the same server in two tabs both complete; (2) a callback whose state has no stored verifier fails with a clear error instead of using another flow's verifier; (3) the CLI/TUI --use-stored-auth hand-off from a web-acquired token still works. Optionally, add a backend setting to keep all web OAuth state per tab, for deployments where one Inspector serves several people.

Before/after: before, any overlap fails all but the last flow to finish its login. With the prototype, every overlapping flow connects and GET /api/storage/oauth holds no codeVerifier.

How it was verified:

• Built 2.11.0 from the tag with the prototype applied (npm install && npm pack, as in the Dockerfile).
• Ran both builds with the same automated browser tests (Chrome via Playwright, Streamable HTTP, a mock authorization server checking PKCE S256):
  • 1 user, 2 overlapping tabs: 2.11.0 fails, the prototype gives 2/2 connected.
  • 6 overlapping users: 2.11.0 gives 1/6, the prototype 6/6, each MCP session carrying its own user's token.
  • Sequential logins, reload and reconnect, and MCP Apps rendering behaved the same with both builds.

Known trade-off of the prototype: each new tab runs its own OAuth flow, and its own DCR registration, as v1 did. The suggested fix avoids that.

Before you submit

• I searched existing issues and this is not a duplicate.
• This is not a security vulnerability report (those go through the private advisory process).