MCP OAuth: Claude Code re-runs DCR on every authenticate, orphaning the previously-issued client_id and its refresh_token

[aria-inboxia]

Summary

When Claude Code's MCP OAuth client runs the authenticate flow for a self-hosted MCP server, it always performs a fresh Dynamic Client Registration (POST /oauth/register) — minting a new client_id / client_secret — even though it already has a perfectly good DCR-issued clientId and clientSecret persisted in Keychain (under Claude Code-credentials → mcpOAuth.<serverName>|<urlHash>) from a previous successful auth.

This silently orphans:

1. The previously-issued client_id on the authorization server (it now has zero live tokens but stays on disk forever).
2. Any refresh_token bound to the old client_id — server-side per RFC 6749 §6, refresh_tokens are scoped to their issuing client, so the new client can never use them.

Combined with refresh-token rotation on the server side, this creates a forced re-auth loop:

1. Session N: authenticate → DCR → client_A, code exchange returns access_A + refresh_A (rotation-eligible).
2. Session N+1 starts, access_A expired. Refresh works once. Server rotates → refresh_A2 (in memory) but client never writes the rotated RT back to Keychain → Keychain still has the now-revoked refresh_A.
3. Session N+2: Keychain has refresh_A, server rejects (revoked), Claude Code triggers full re-auth → another DCR → client_B. Now both client_A and client_B exist server-side; client_A is orphaned.
4. Repeat forever.

Reproduction

Self-hosted MCP server implementing OAuth 2.1 + RFC 7591 DCR + RFC 9728:

// ~/.claude.json
{
  \"mcpServers\": {
    \"example\": { \"type\": \"http\", \"url\": \"https://example.com/mcp\" }
  }
}

1. /mcp authenticate example — completes successfully, Keychain stores clientId=mcp_client_AAAA, clientSecret=..., accessToken=..., refreshToken=....
2. Wait until access_token expires (or kill the session).
3. /mcp authenticate example again. Observed: Claude Code calls POST /oauth/register and gets a brand new client_id=mcp_client_BBBB, ignoring the stored mcp_client_AAAA.
4. Server-side: 2 client records, only the new one has a refresh_token.

Expected

If mcpOAuth.<serverName>|<urlHash>.clientId is already populated and the auth-server discovery URL hasn't changed, Claude Code should:

• Reuse the persisted clientId / clientSecret and skip POST /oauth/register entirely.
• Re-run POST /oauth/register only if the discovery URL changed, OR if a token endpoint returns invalid_client for the stored client (i.e. the client was revoked / DB wiped server-side).

This matches MCP spec §6.1.4 ("The client SHOULD store the client_id ... and reuse it for subsequent authorization flows") and how every well-behaved OAuth 2.1 client (Postman, VS Code's MCP client, Cline, etc.) handles DCR persistence.

Evidence

Server-side /oauth/register log over 48h on a single MCP server, only one human user, only one Mac:

mcp_client_HzpTW59SRgpP-CkO3th  2026-05-14 11:47:26
mcp_client__nyNwtiOQ7q6yRiG22u  2026-05-14 11:48:16
mcp_client_9v64hQw6jnitSJcZxjC  2026-05-14 11:52:34  Claude Code (scalarly-memory)
mcp_client_rs80IIyAbpeZe_PWnO-  2026-05-14 11:55:55  Claude Code (scalarly-memory)
mcp_client_D6bFpKkwKK9OW8pKkWI  2026-05-14 11:57:43  Claude Code (scalarly-memory)
...30+ rows over 48h, all with client_name='Claude Code (...)', all but the latest with zero live tokens.

Keychain snapshot of an established slot (redacted) BEFORE and AFTER a fresh authenticate:

  scalarly-memory|<hash>:
    serverName: \"scalarly-memory\"
    serverUrl: \"https://example.com/mcp\"
    discoveryState: {authorizationServerUrl: \"...\", oauthMetadataFound: true}
-   clientId: \"mcp_client_AAAA\"
-   clientSecret: \"...\"
-   accessToken: \"<expired>\"
+   clientId: \"mcp_client_BBBB\"   # ← fresh DCR despite AAAA being valid
+   clientSecret: \"...\"
+   accessToken: \"<fresh>\"
+   refreshToken: \"<fresh>\"
+   expiresAt: <now+3600s>
+   scope: \"read write admin\"

Impact

1. Forced re-auth loop: combined with server-side refresh-token rotation (which is recommended by RFC 6749 §10.4), users SSO every session. Many self-hosted MCP servers behind Cloudflare Access / Okta / similar mean every re-auth requires an interactive browser SSO step. UX disaster.
2. Server DB bloat: each authenticate adds a permanent oauth_clients row. After 30 sessions, the server has 30 orphan clients with no tokens. Manual cleanup required.
3. No way to map auth events to users: server logs show "client X authorized", but X changes every session, breaking per-client analytics / audit trails.
4. Risk vector: an attacker who compromises the auth server can't easily tell which mcp_client_* is the user's current one, but neither can the user. Token-leak triage becomes harder.

Workarounds

Server-side: disable refresh-token rotation (downgrades RFC 6749 §10.4 protection but eliminates the forced-reauth pattern).

Client-side: none — the orphaning happens regardless of any server config.

Suggested fix in Claude Code

In the MCP OAuth client path that handles authenticate:

if keychain.mcpOAuth[serverKey].clientId and not force_re_register:
    use persisted clientId+clientSecret, skip DCR
else:
    POST /oauth/register, store result

The "force" branch fires when the stored client is rejected (invalid_client on the token endpoint) or when the auth server URL has changed. Same protocol contract, no fresh registration per session.

Environment

• Claude Code version: latest stable (Opus 4.7 main session, 2026-05-15)
• macOS 25.4 / Darwin 25.4.0
• MCP server: open-source mcp-memory-service (FastAPI + RFC 9728 + DCR + PKCE + refresh rotation)

Related

• Support pre-configured OAuth client credentials without requiring Dynamic Client Registration #26675 — pre-configured OAuth client credentials without DCR (complementary: that issue asks to skip DCR entirely for providers that don't support it; this issue asks to reuse DCR-issued creds when they exist)

[arjunkmrm]

Confirming this repros against a Smithery-hosted MCP server (auth server https://auth.smithery.run). Same forced-reauth-every-session symptom. Tested with claude-code/2.1.142 — post the v2.1.136 fix in #28256.

Ran a spec-compliant MCP OAuth client (PKCE + DCR + loopback) to complete the initial code grant, then three raw curls against the token endpoint to verify the server's rotation contract:

# Initial grant → refresh_token_v1

# 1st refresh with v1 → 200, server rotates to v2
# 2nd refresh re-using v1 → 400 {"error":"invalid_grant","error_description":"Invalid or expired refresh token"}
# 3rd refresh with v2 → 200, server rotates to v3

Single-use rotation per RFC 6749 §10.4 — server is correct. So when claude-code refreshes but doesn't persist the rotated token, the next session reads the old (now-revoked) one from Keychain, gets invalid_grant, falls back to a fresh authorize + DCR, orphans the client.

The OP's mcp-memory-service is self-hosted; this is a hosted production toolbox. Same bug class — affects any MCP server that follows the recommended OAuth 2.1 + rotation pattern.

Server-side mitigation (turning off rotation) downgrades RFC 6749 §10.4 protection and doesn't fix the DCR-orphaning half. Fix has to live in the client.

Both parts of OP's proposed fix apply:

1. Persist the rotated refresh_token from every token response, not just the initial grant.
2. Reuse stored clientId / clientSecret on re-authenticate instead of unconditional DCR.

Without (1), (2) doesn't help (stored RT is already revoked). Without (2), (1) doesn't help (server accumulates orphan clients).

[ezwep]

Confirming this also reproduces against a self-hosted MCP server (OAuth 2.1 AS + RFC 7591 DCR + RFC 9728), and adding one observation about the server-side blast radius that turns this from "stale refresh token, redo the flow" into a hard outage.

Setup

• Server: self-hosted, OAuth 2.1 + RFC 7591 + RFC 9728, hosted on Azure Container Apps behind a corporate egress.
• Server has a per-IP rate limit on /oauth/register of 5 / hour / IP (in-memory store per replica, per RFC 7591 §5 / OWASP API4 — anonymous endpoint that writes a DB row, so it's a textbook abuse target).
• Clients: Claude Desktop macOS (custom connector UI) and Claude Code CLI. Same symptom class on both surfaces, so this is the shared MCP OAuth client code path, not Claude-Code-specific.

Failure mode we observed

1. User A added the connector, authorized successfully, used it. Keychain holds client_A + refresh_A.
2. We added User B to the access group on the IdP. User B clicked Authenticate → IdP rejects (group propagation delay) → Claude treats this as a stale-registration and re-runs DCR. New client_B. Server-side rate-limit slot consumed.
3. User B retried a few times. Each retry minted a fresh DCR call. After 5 attempts the per-IP rate limit was exhausted (same corporate egress NAT as User A + diagnostic curls).
4. From then on every Claude attempt — for User A and User B — returned HTTP 429 {"error":"rate_limited"} from /oauth/register.
5. Claude renders this as SDK auth failed: with no body in the connector card. No error, no error_description, no Retry-After. The user has no actionable signal.

Why the rate-limit matters here (it shouldn't be the breaking factor)

5/hour/IP on DCR is a deliberate, conservative number — RFC 7591 §5 explicitly calls out DCR as an abuse target, and Spec authors expect clients to register once and persist. Our limit is fine for legitimate use; it should never be reached in normal operation.

But because Claude re-runs DCR every authenticate (per OP), and because multi-user installs share a corporate egress IP, the limit gets eaten quickly by legitimate activity:

• N users behind one NAT × M auth retries per failed-IdP-permission scenario = quota exhausted in minutes.
• One user can lock out the rest of their org for an hour.

This is exactly the abuse-prevention rate-limit doing its job — but against the client, not an attacker.

Two requests

1. Persist + reuse on retry, per OP — already covered, just confirming.
2. Surface the 429 to the user. Right now Claude swallows the OAuth error response into an empty SDK auth failed: banner. If the rate-limit body ({"error":"rate_limited"}) or the Retry-After header reached the UI, the user (and IT) would immediately know to wait / scale the limit instead of retrying and burning more quota. Per RFC 6749 §5.2 / RFC 7591 §3.2.2, the OAuth error JSON is the canonical signal — the SDK should at least pass it through.

Diagnostic data (in case useful)

• Server-side: HTTP/2 429, content-type: application/json, body {"error":"rate_limited"}, with Retry-After: <seconds> + Cache-Control: no-store + standard RateLimit-Limit / -Remaining / -Reset headers. So the SDK has everything it needs to show a real message.
• Client-side (Claude Desktop, macOS): only "SDK auth failed:" rendered in the MCP connector card. No log entry in ~/Library/Logs/Claude/main.log or claude.ai-web.log for the failure.

Happy to provide a sanitized HAR / server log if it helps narrow down whether the 429 body is being dropped at the transport layer or at the UI layer.

[AndrewHannigan]

Confirming on v2.1.153 with a self-hosted MCP cluster (Toolhive operator v0.29.1, refresh_token TTL 168h, RT rotation enabled). Adding evidence that this failure mode can fire without the DCR-on-every-authenticate path you describe — the orphan-clientId story is one trigger, but there's a per-MCP batch-refresh write race that also produces the same end-state.

Observation. At 2026-06-05T11:47:31Z a single Claude Code session ran proactive token refresh against three Toolhive-fronted MCPs (LaunchDarkly, UserVoice, Temporal) in series, within a 70ms window. Server-side, all three embedded auth servers issued new (access_token, refresh_token) pairs and rotated the old RTs — confirmed in the auth server's Redis store with requested_at timestamps 11:47:31.344Z / .373Z / .414Z. Only Temporal ended up with the new tokens in the macOS Keychain. The LaunchDarkly and UserVoice keychain entries kept their pre-rotation refresh_token; clientId was unchanged in both — and matches the clientId on the new Redis RT record, so DCR didn't re-run. This isn't the orphan-clientId path; it's a partial-write across MCPs in the same refresh batch.

~75 minutes later the next session started, read the stale RT from keychain, sent it to /oauth/token, and got invalid_grant:

Token refresh failed with invalid_grant: The provided ... refresh token
is invalid, expired, revoked, ... or was issued to another client.
No valid tokens in storage, clearing stored tokens
Invalidated credentials (scope: tokens)

…for LaunchDarkly and UserVoice. Token refreshed successfully for Temporal in the same session at the same moment. After this, the affected keychain entries have accessToken="", refreshToken absent, expiresAt=0, with clientId and redirectUri preserved — UI shows "needs authentication." Server-side, the rotated RT issued at 11:47:31Z is still alive in Redis with a 2026-06-12T11:47:31Z expiration; the server's 7-day promise is intact, the client just can't reach the token without a fresh browser flow.

Suggestion (in addition to the DCR-reuse fix in your original report): in the MCP refresh path, when invalid_grant is returned, re-read storage once more and check whether any RT has been written since the in-flight refresh started — mirroring the existing recovery on the gateway-refresh path ([gateway-refresh] auth changed mid-refresh; discarding invalid_grant). The MCP path appears to go straight to clearStoredTokens() on invalid_grant; I don't see an equivalent recovery string in the binary.

Happy to share more (server-side Redis records linking user → clientId → rotated RT, per-process --mcp-debug logs across worktrees) if it'd help reproduce.

[babiaraujo]

Reproducing on a self-hosted OAuth MCP server: the native connector completes auth, drops the token, then loops on DCR — mcp-remote works against the identical URL.

Same symptom here. The native remote connector ("Add custom connector") completes the browser auth flow, then immediately reverts with:

Your account was authorized but the integration rejected the credentials, so the connection was reverted

(McpAuthorizationError).

The token is issued correctly — the connector just never sends it on the MCP request, and instead re-registers the DCR client in a loop, orphaning every client_id it gets.

Server-side trace (production)

1. GET /authorize?…&resource=https://api.example.com/backoffice/mcp&scope=mcp:tools&code_challenge_method=S256&redirect_uri=https://claude.ai/api/mcp/auth_callback → 302
2. POST /token → 200 — access token issued to the connector backend (UA python-httpx/0.28.1)
3. The connector POSTs to the MCP endpoint without an Authorization header (our middleware logs hasAuthorizationHeader: false) → 401
4. The connector re-registers the client in a loop (POST /register → 201, repeatedly, within seconds), never reusing the prior client_id. Every issued client_id / token gets orphaned.

Ruled out — it's not the server or the edge

• ✅ Server is healthy. mcp-remote (npx) hits the same URL and completes initialize (200). Only the native server-side connector fails.
• ✅ Cloudflare isn't stripping Authorization. A test request carrying a bearer reaches our origin and is logged as an invalid token — header present. The native connector simply doesn't send one.
• ✅ OAuth metadata is RFC-compliant. PRM (RFC 9728) and AS metadata (RFC 8414) byte-match the connect URL on resource / issuer; token_type: "Bearer"; PKCE S256; token_endpoint_auth_method: "none".

DCR detail

/register returns 201 with client_id, redirect_uris, grant_types, response_types, token_endpoint_auth_method, scope. We've since added client_id_issued_at + client_secret_expires_at (RFC 7591 §3.2.1) to see whether that helps the connector persist/reuse the client — will report back.

Net

The connector obtains a valid token via /token but never attaches it to the MCP request, and keeps re-registering — orphaning the client_id. mcp-remote against the same server is fine, which points at the native connector's token handling / persistence rather than the server or the edge.

Environment

Transport	Streamable HTTP (stateless, enableJsonResponse: true)
Auth	OAuth 2.1 · DCR (RFC 7591) · PKCE S256 · public client
Edge	Cloudflare (proxied) → Node/Express origin
Clients	❌ claude.ai / Desktop native connector · ✅ mcp-remote

Happy to share HAR captures and server logs by trace_id. Any known workaround or ETA? This blocks server-side org connectors for us today.