Claude Enterprise — Custom Connector OAuth Token Not Refreshing

[danielserranoh]

MCP server URL

https://api.atlas.griddo.io/mcp/

Where does the issue occur?

During a conversation (after initial auth)

Transport used

streamable-http

Client registration type

Dynamic Client Registration (DCR)

SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

When did you last reproduce this?

2026-05-01 between 02:02:11Z and 02:05:11Z (UTC). Additional reproductions through ~03:00Z UTC during the same debugging session.

Browser and OS

Claude Cowork (in claude desktop)

Describe the issue

A Custom Connector pointing to an MCP server that exposes OAuth 2.1 protected resource metadata (/.well-known/oauth-protected-resource) becomes permanently unusable after its OAuth access token expires. Claude does not refresh the token using the refresh_token grant the resource server advertises, and reinstalling the connector through the Enterprise admin console does not clear the stale state — the same UUID, the same tool permissions, and the same expired credentials are restored without prompting the user for re-authentication.

The end-user symptom is a hard, repeating 401 Invalid or expired token for every tool call against the connector.

We ran a multi-hour debugging session that ruled out client-side caches, local environment variables, MCP proxy state and mcp-remote configuration as the root cause. Server-side logging on our MCP server confirmed that the failing requests originate from Anthropic's cloud bridge (User-Agent Claude-User, IPs in the 160.79.106.0/24 range) and carry an OAuth access token whose exp claim is in the past. The same connector configuration works in the very narrow window during which the token is still valid, then fails permanently.

The four issues we surfaced, in order of impact:

1. No automatic OAuth token refresh. The bridge keeps using an expired token instead of using the refresh_token grant that the resource server advertises in its authorization-server metadata.
2. "Delete" of a Custom Connector does not purge server-side state. Reinstalling reuses the same connector UUID, restores tool permissions, and silently reuses cached credentials — the UI never re-prompts for auth.
3. Marketplace plugin freezes ${ENV_VAR} substitution at install time. Updating the env var (or the .mcp.json) and re-installing does not re-resolve the variable; the resolved value lives in a cache that survives uninstall/reinstall cycles.
4. Cowork agent runtime appears to share the connector's broken state with the interactive UI, so a stale OAuth state in one surface poisons all surfaces. There is no surfaced way to refresh it from inside Cowork.

We strongly suspect (1) is the root cause and the rest are aggravating factors. The fix on Anthropic's side would unblock everyone who ships an OAuth-protected MCP server through Custom Connectors.

Issue details

##  The Bug, Reproduced End-to-End

1. User adds a Custom Connector via the Enterprise console pointing at an MCP server that exposes `/.well-known/oauth-protected-resource`.

2. Claude detects OAuth metadata and forces an OAuth flow. It does **not** offer the user a Bearer / API-key option in the UI.

3. User completes OAuth login on the personal account. Tools become available.

4. After the OAuth access token expires (in our case `exp=1777602883`, ~24 h after issuance), every tool call returns:

   
   {"success":false,"error":{"message":"Invalid or expired token","status_code":401}}
   

5. Disconnecting and reconnecting the connector from the user's account does not refresh the token.

6. Deleting the connector at the org-admin level and reinstalling it preserves: (a) the connector UUID, (b) tool permissions, (c) the cached credentials. Anthropic's UI does not re-prompt for auth on reinstall.

7. Restarting Claude does not help. Clearing local caches (`~/.mcp-auth`, `claude_desktop_config.json`, `launchctl` env, killing `mcp-remote` zombies) does not help.

8. Server-side logging confirms requests are arriving with an OAuth access token whose `exp` claim is in the past. The same server, queried directly with `curl` and a valid token, returns `200 OK`. So the server is healthy; the bridge is sending stale credentials.

Expected behavior

The mcp actually working.

Logs from your server

[
  "INFO - Session 4a605aa00c154a3281f782a691ff81c4 idle timeout                    ",
  "INFO - Terminating session: 4a605aa00c154a3281f782a691ff81c4                    ",
  "INFO - Session f753e0ca8db3409493aa04f683f2cebb idle timeout                    ",
  "INFO - Terminating session: f753e0ca8db3409493aa04f683f2cebb                    ",
  "INFO:     169.254.172.2:37734 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:37308 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.3:45748 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:35096 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:51058 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.3:36354 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:56306 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:36468 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.3:42124 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:52926 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:40160 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.3:52262 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:46624 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:58858 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.3:32824 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:34790 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO - Session 9238a1c422f34634b8f1500acc6af2dd idle timeout                    ",
  "INFO - Terminating session: 9238a1c422f34634b8f1500acc6af2dd                    ",
  "INFO - Session 7203b0adf7764a549552762c1bd4bbf5 idle timeout                    ",
  "INFO - Terminating session: 7203b0adf7764a549552762c1bd4bbf5                    ",
  "INFO - Session 0feafada98db4a4cadf7a493cdde5474 idle timeout                    ",
  "INFO - Terminating session: 0feafada98db4a4cadf7a493cdde5474                    ",
  "INFO:     169.254.172.2:51924 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.3:33046 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:46254 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:54904 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.3:50810 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:49178 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:52876 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.3:40810 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:50604 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:56402 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.3:45148 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:38772 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:38526 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.3:46796 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:42390 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:52886 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.3:38530 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:45086 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:54254 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.3:40712 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:51086 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:57808 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.3:50120 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:36950 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO - [MCP-AUTH-DEBUG] POST /mcp/ | ip=81.40.140.120 | auth=Bearer             ",
  "eyJhbGciOiJIUzI1NiIs...IhIza93A (len=260)                                       ",
  "claims={sub='277b2804-e7f8-4899-97d4-f4cb7a0dbead',type='mcp_api_key',exp=?} |  ",
  "ua=node                                                                         ",
  "INFO:     169.254.172.3:50136 - \"POST /mcp/ HTTP/1.1\" 404 Not Found",
  "INFO - [MCP-AUTH-DEBUG] POST /mcp/ | ip=81.40.140.120 | auth=Bearer             ",
  "eyJhbGciOiJIUzI1NiIs...IhIza93A (len=260)                                       ",
  "claims={sub='277b2804-e7f8-4899-97d4-f4cb7a0dbead',type='mcp_api_key',exp=?} |  ",
  "ua=node                                                                         ",
  "INFO:     169.254.172.3:50140 - \"POST /mcp/ HTTP/1.1\" 404 Not Found",
  "INFO:     169.254.172.2:48516 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.3:57990 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO - [MCP-AUTH-DEBUG] GET /mcp | ip=160.79.106.37 | auth=Bearer               ",
  "eyJhbGciOiJIUzI1NiIs...C3avHeH0 (len=475)                                       ",
  "claims={sub='277b2804-e7f8-4899-97d4-f4cb7a0dbead',type='?',exp=1777602883} |   ",
  "ua=Claude-User                                                                  ",
  "INFO:     169.254.172.3:57996 - \"GET /mcp HTTP/1.1\" 404 Not Found",
  "INFO - [MCP-AUTH-DEBUG] GET /mcp | ip=160.79.106.38 | auth=Bearer               ",
  "eyJhbGciOiJIUzI1NiIs...C3avHeH0 (len=475)                                       ",
  "claims={sub='277b2804-e7f8-4899-97d4-f4cb7a0dbead',type='?',exp=1777602883} |   ",
  "ua=Claude-User                                                                  ",
  "INFO:     169.254.172.3:57996 - \"GET /mcp HTTP/1.1\" 404 Not Found",
  "INFO - [MCP-AUTH-DEBUG] POST /mcp | ip=160.79.106.35 | auth=Bearer              ",
  "eyJhbGciOiJIUzI1NiIs...C3avHeH0 (len=475)                                       ",
  "claims={sub='277b2804-e7f8-4899-97d4-f4cb7a0dbead',type='?',exp=1777602883} |   ",
  "ua=Claude-User                                                                  ",
  "INFO:     169.254.172.3:57996 - \"POST /mcp HTTP/1.1\" 404 Not Found",
  "INFO - [MCP-AUTH-DEBUG] POST /mcp | ip=160.79.106.35 | auth=Bearer              ",
  "eyJhbGciOiJIUzI1NiIs...C3avHeH0 (len=475)                                       ",
  "claims={sub='277b2804-e7f8-4899-97d4-f4cb7a0dbead',type='?',exp=1777602883} |   ",
  "ua=Claude-User                                                                  ",
  "INFO - Created new transport with session ID: 8da40d59b68c43ed8c79873cbbb93c6a  ",
  "INFO:     169.254.172.3:57996 - \"POST /mcp HTTP/1.1\" 200 OK",
  "INFO - [MCP-AUTH-DEBUG] POST /mcp | ip=160.79.106.35 | auth=Bearer              ",
  "eyJhbGciOiJIUzI1NiIs...C3avHeH0 (len=475)                                       ",
  "claims={sub='277b2804-e7f8-4899-97d4-f4cb7a0dbead',type='?',exp=1777602883} |   ",
  "ua=Claude-User                                                                  ",
  "INFO:     169.254.172.3:57996 - \"POST /mcp HTTP/1.1\" 202 Accepted",
  "INFO - [MCP-AUTH-DEBUG] GET /mcp | ip=160.79.106.37 | auth=Bearer               ",
  "eyJhbGciOiJIUzI1NiIs...C3avHeH0 (len=475)                                       ",
  "claims={sub='277b2804-e7f8-4899-97d4-f4cb7a0dbead',type='?',exp=1777602883} |   ",
  "ua=Claude-User                                                                  ",
  "INFO:     169.254.172.3:57996 - \"GET /mcp HTTP/1.1\" 200 OK",
  "INFO:     169.254.172.2:36622 - \"GET /api/health HTTP/1.1\" 200 OK",
  "INFO - [MCP-AUTH-DEBUG] POST /mcp | ip=160.79.106.37 | auth=Bearer              ",
  "eyJhbGciOiJIUzI1NiIs...C3avHeH0 (len=475)                                       ",
  "claims={sub='277b2804-e7f8-4899-97d4-f4cb7a0dbead',type='?',exp=1777602883} |   ",
  "ua=Claude-User                                                                  ",
  "INFO:     169.254.172.3:58010 - \"POST /mcp HTTP/1.1\" 200 OK",
  "INFO - Processing request of type CallToolRequest                               "
]

Additional context

• macOS 14.x (Apple Silicon)
• Claude desktop app version 1.5354.0
• Plan: Claude Enterprise (org admin)
• Two surfaces tested: interactive Claude.app chat and Cowork agent mode
• MCP transport: HTTP via npx -y mcp-remote (locally) and via Anthropic's hosted bridge (Custom Connector)
• MCP server: https://api.atlas.griddo.io/mcp/, FastAPI behind AWS App Runner / Envoy. Server-side OAuth metadata published at /.well-known/oauth-protected-resource/mcp and /.well-known/oauth-authorization-server. Supports both static mcp_api_key Bearer tokens and full OAuth 2.1 with PKCE and dynamic client registration (RFC 7591) including refresh_token grant.

anthropic-bug-report-custom-connector-oauth.md

[danielserranoh]

Follow-up: found a likely contributing root cause in the Python MCP SDK (1.27.0)

While debugging this from the server side I tried to reproduce the OAuth dance against my own /mcp/ with MCP Inspector (@modelcontextprotocol/inspector) — same OAuth metadata, same DCR-registered client, same network path, just a different OAuth client. It failed at the /token exchange with:

HTTP/1.1 401 Unauthorized
{"error":"unauthorized_client","error_description":"Missing client_id"}

…even though the request was perfectly well-formed:

POST /mcp/token HTTP/1.1
Authorization: Basic <base64(client_id:client_secret)>
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=…&code_verifier=…&redirect_uri=…&resource=…

This is RFC 6749 §2.3.1 client_secret_basic — credentials in the Authorization: Basic header, not redundantly repeated in the form body. The Inspector is doing exactly what the spec says.

Where the bug lives

mcp.server.auth.middleware.client_auth.ClientAuthenticator.authenticate_request (mcp 1.27.0):

async def authenticate_request(self, request: Request) -> OAuthClientInformationFull:
    form_data = await request.form()
    client_id = form_data.get(""client_id"")
    if not client_id:
        raise AuthenticationError(""Missing client_id"")  # ← always fires for Basic-auth clients
    ...

The handler unconditionally requires client_id in the form body before even looking at the Basic header. Per RFC 6749 §2.3.1 the spec-compliant behaviour is the opposite: when credentials are correctly delivered in Authorization: Basic, the body's client_id is optional. Several mainstream OAuth clients (MCP Inspector, requests-oauthlib, oauth2-proxy, Auth0 Node SDK at default settings) ship client_id only in the Basic header.

Why this likely matters for issue #247

The reported symptom is that Claude's cloud bridge keeps using an expired access token instead of using the refresh_token grant. From the server I can confirm the bridge does send pre-expiry grant_type=refresh_token requests (we logged them under MCP_AUTH_DEBUG=true in a separate window). If the bridge happens to deliver client credentials via Basic auth — which is the more secure of the two methods declared in our metadata and is what RFC 9700 (OAuth 2.0 Security BCP) recommends — every refresh attempt would 401 with the exact same Missing client_id error, and the bridge would be left holding a token that's about to expire with no successful refresh path. That looks identical to the symptom in this issue: the token expires and from then on every tool call returns 401.

I haven't been able to instrument the bridge directly, but it's the simplest hypothesis that fits all the observed evidence: refresh attempts that the SDK silently rejects → bridge falls back to the cached (now-expired) access token → user sees permanent 401s on every tool call.

Server-side workaround we shipped

For anyone hitting this while it's open: I shipped a small ASGI middleware in front of /mcp/token that decodes the Basic header and injects client_id into the form body when missing, so the SDK sees what it expects. Diff: https://github.com/griddo/university_etl/pull/32 (file interfaces/api/middleware/oauth_basic_to_form.py). It's a no-op on every other path/method/content-type and on requests that already carry client_id in the body.

This unblocked Inspector immediately. If the diagnosis above is correct, after the same fix lands here the existing Custom Connector token should also start refreshing on its own — the bridge wouldn't need any change.

Suggested upstream fix

In mcp.server.auth.middleware.client_auth.ClientAuthenticator.authenticate_request, when client_id is missing from the body, fall back to extracting it from the Authorization: Basic header before raising AuthenticationError. The handler already decodes the Basic header further down — it just needs to do it earlier.

Happy to put a PR up against the SDK if it's helpful; let me know which surface owns this (claude-ai-mcp vs. modelcontextprotocol/python-sdk).

— Daniel Serrano (daniel.serrano@griddo.io)

[danielserranoh]

Update — third independent bug found in the same debugging session

After the SDK workaround landed, the OAuth dance with MCP Inspector completed cleanly but the very next call (notifications/initialized) was rejected by my own server with Bad Request: Missing session ID. Cause turned out to be a CORS configuration gap on my side, not Anthropic's:

• Streamable HTTP transport returns the new session as the Mcp-Session-Id response header on initialize. Clients must echo it on every follow-up POST.
• Browsers strip custom response headers from cross-origin responses unless the server lists them in Access-Control-Expose-Headers. The Inspector runs at http://localhost:6274, hits https://api.atlas.griddo.io/mcp/, and never sees the header → no session ID to echo → server-side rejection.

Fix on my server (fastapi.middleware.cors.CORSMiddleware):

app.add_middleware(
    CORSMiddleware,
    ...,
    expose_headers=["Mcp-Session-Id", "mcp-session-id"],
)

This is scoped to browser-based MCP clients (Inspector, future web-based integrations). Native clients — Claude Desktop, mcp-remote, the Custom Connector bridge — don't enforce CORS, so this does not affect the original issue described above. Flagging it here only because it's a gotcha that anyone reading this thread who tries to reproduce with MCP Inspector will hit, and it has nothing to do with the upstream bridge's refresh-token behaviour.

End-to-end status now:

• ✅ MCP Inspector → Atlas: full session works (OAuth + initialize + tool calls).
• ❌ Custom Connector → Atlas: still pending, gated on the SDK fix described in my previous comment (or equivalent on the bridge side).

— Daniel Serrano (daniel.serrano@griddo.io)

[danielserranoh]

Final status — server-side end-to-end works with MCP Inspector

After deploying the workaround for the SDK client_secret_basic issue (plus a couple of unrelated CORS / audience-claim gaps that were on my side, not Anthropic's), the full flow with MCP Inspector now succeeds end-to-end against https://api.atlas.griddo.io/mcp/: OAuth dance → initialize + notifications/initialized → tools/list → real tool execution returning data.

The two items that remain on Anthropic's side are unchanged from my earlier comments:

1. MCP Python SDK (mcp.server.auth.middleware.client_auth.ClientAuthenticator): require client_id from the body OR fall back to extracting it from Authorization: Basic per RFC 6749 §2.3.1. Happy to send a PR if you point me to the right repo.
2. Custom Connector bridge / Claude Enterprise (the original issue): proactively use the advertised refresh_token grant before the access token's exp instead of reusing the expired one. If the bridge happens to deliver client credentials via Basic auth, fixing (1) would also unblock this on its own.

Closing this loop on my side. Reach out if more server-side traces or repros would help.

— Daniel Serrano (daniel.serrano@griddo.io)

[ethirolle]

Adding independent server-side confirmation of the "reinstall doesn't clear stale state" behavior described above, from a different MCP server/org (also Claude Enterprise, org-directory-published custom connector, OAuth 2.1 + PKCE + DCR, Google as upstream IdP via a FastMCP OAuthProxy).

Symptom (user-facing): intermittent tool-call failures reported as "tool not available in my current toolset" in Claude.ai chat. The affected user disconnected and reconnected the connector (the only self-service action available for an org-directory-published connector — no per-user remove/re-add) and still saw the same failure afterward.

Server-side evidence: we added temporary diagnostic logging around our OAuth token-verification path specifically to investigate this. It shows:

OAuth client lookup failed: client_id=<uuid> not found in client store
OAuth token rejected: invalid FastMCP JWT (bad signature or expired)

i.e. the client presents a client_id that no longer exists in our server's DCR client registry, and the same request pattern recurs across multiple different affected client_ids over several hours. Critically, across a multi-hour window covering several of these failures (including immediately after the user's disconnect/reconnect), our access logs show zero /register, /authorize, /consent, or /auth/callback requests — i.e. reconnect did not trigger a fresh DCR + consent flow server-side, consistent with the client reusing a cached client_id/token rather than re-registering.

We confirmed (via direct Firestore lookups, since our OAuth state store happens to be queryable) that the specific client_ids being retried were registered weeks earlier — i.e. genuinely stale client registrations from well before the failures started, not something newly broken on our end.

One data point that may be useful: in one case, leaving the connector disconnected for roughly 15+ minutes before reconnecting did result in a successful reconnect (fresh tool calls worked afterward). We don't have visibility into why — could be consistent with the retry/backoff-eventually-reprobes behavior described in #379, rather than a deliberate cache TTL — but wanted to flag it in case it's a useful signal on your side.

Happy to share full (redacted) server logs or exact timestamps if that would help trace this on Anthropic's side.