MCP client does not retry authenticated request after successful OAuth token exchange

[jkgibson-source]

Initial Checks

• I confirm that I'm using the latest version of MCP Python SDK
• I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue

Description

MCP client does not retry authenticated request after successful OAuth token exchange

Summary

The Claude.ai MCP client (identified as python-httpx/0.28.1 in nginx logs) completes the full OAuth 2.0 authorization code flow — including a successful POST /oauth/token response — but never sends an authenticated follow-up request to GET /sse (or POST /sse) with the issued Bearer token. The connection silently fails after token issuance.

Environment

• Client: Claude.ai web app / Claude mobile app (iOS)
• MCP client user-agent: python-httpx/0.28.1
• Server: Custom MCP SSE server (FastMCP + Starlette + uvicorn, behind Cloudflare tunnel + nginx)
• Transport: SSE (mcp.sse_app())
• MCP spec version: 2025-03-26
• Auth: Custom OAuth 2.0 implementation with dynamic client registration

Steps to Reproduce

1. Stand up an MCP SSE server with OAuth 2.0 per the 2025-03-26 spec
2. Expose it via a public HTTPS URL
3. Add the server URL to Claude.ai
4. Observe: the app discovers OAuth metadata, registers a client, completes the authorization code + PKCE flow, receives a 200 from POST /oauth/token with a valid Bearer token
5. Observe: no further requests arrive at the server. The app does not retry GET /sse or POST /sse with Authorization: Bearer <token>

Expected Behavior

After receiving a valid token from POST /oauth/token, the client should retry the original SSE connection request with Authorization: Bearer <token> in the header.

Actual Behavior

Nginx access logs confirm zero authenticated requests arrive after token issuance. The OAuth flow completes successfully on the server side and the connection is dropped client-side.

Evidence the Server Is Working Correctly

Manual curl with a valid Bearer token successfully opens the SSE stream and receives a properly-formed MCP response:

curl -s -X POST "https://theburrow.dev/sse" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"curl-test","version":"1.0"}},"id":1}'

Response:

HTTP/2 200
content-type: text/event-stream
mcp-session-id: <redacted>

<img width="1079" height="1034" alt="Image" src="https://github.com/user-attachments/assets/2e46a305-a74f-4338-b561-bfbc286b1718" />

event: message
data: {"jsonrpc":"2.0","id":1,"error":{"code":-32602,"message":"Invalid request parameters"}}

The -32602 error is expected (test curl was missing clientInfo) — the point is the server accepted the token, opened the stream, and responded over SSE. The full stack is functional.

OAuth Sequence Confirmed Working (from nginx logs)

GET  /.well-known/oauth-protected-resource   → 200
GET  /.well-known/oauth-authorization-server → 200
POST /oauth/register                          → 200
GET  /oauth/authorize                         → 307 (redirect to claude.ai callback)
POST /oauth/token                             → 200
[no further requests]

Additional Notes

• The initial probe is POST /sse → 405, which appears to trigger OAuth discovery. This is not a GET /sse → 401 + WWW-Authenticate flow as specified — it's possible the app's retry logic after 405-triggered OAuth is different from the 401-triggered path and the reconnect target URL is getting lost.
• The server does return 401 + WWW-Authenticate: Bearer on unauthenticated GET /sse requests (added during debugging). This did not change the behavior.
• Tested on both Claude.ai web and Claude mobile (iOS). Same result on both.

Example Code

Python & MCP Python SDK

Python 3.11
MCP Python SDK 1.27.1

[mcp-claude]

cannot reproduce with current SDK on main (161834d) or v1.x (77431eb).

the sse_client + OAuthClientProvider auth flow works correctly: initial GET /sse → 401 triggers the full OAuth dance and the retry request arrives at the server with Authorization: Bearer <token>. tested end-to-end with a mock transport.

the reporter's key clue is the initial probe POST /sse → 405. two relevant SDK facts:

1. sse_client always uses GET, not POST — no SDK code makes POST /sse
2. async_auth_flow only starts OAuth on 401 or 403; a 405 response just exits the generator with no retry

so either the POST comes from streamable_http_client (which is likely if claude.ai probes for that transport first), or from claude.ai's own code. either way, a 405 will never trigger the SDK's OAuth retry path.

the reporter also says that adding 401 + WWW-Authenticate on GET /sse didn't change behaviour. that implies claude.ai isn't sending an unauthenticated GET /sse at all, which puts the missing retry in claude.ai's application layer (closed source), not in the SDK.

to reopen this we'd need:

1. a runnable script using only the public SDK (e.g. sse_client / streamable_http_client) that shows the authenticated request not arriving after a successful POST /oauth/token
2. the exact SDK entry point claude.ai is calling (which function, which auth handler)
3. server-side logs showing the full request sequence including the initial GET /sse attempt (not just the oauth endpoints)

repro script + output (both branches pass)

repro.py (full source in attached file)

uv run python repro.py

output (main 161834d and v1.x 77431eb — identical):

============================================================
Verifying async_auth_flow only triggers OAuth on 401/403
============================================================
  async_auth_flow handles 401: True
  async_auth_flow handles 403: True
  async_auth_flow handles 405: False

  Confirmed: OAuth only triggers on 401/403.
  If client receives POST /sse → 405 first, auth flow does NOT
  trigger OAuth from that response — no retry will happen.

============================================================
Test: sse_client OAuth retry after 401
============================================================
  [redirect_handler] auth URL received ...
  [callback_handler] returning code + state=...

SSE connection established!
Requests log:
  GET /sse auth=False
  GET /.well-known/oauth-protected-resource auth=False
  GET /.well-known/oauth-authorization-server auth=False
  POST /oauth/register auth=False
  POST /oauth/token auth=False
  GET /sse auth=True                          ← authenticated retry present

PASS: OAuth retry worked — authenticated SSE request was made.

code path:
sse_client → aconnect_sse(client, "GET", url) → client.stream("GET", url) → httpx._send_handling_auth loops through the auth flow generator. each intermediate request (PRM, OASM, register, token) is sent and its body is read. the final yield request at oauth2.py:621 causes httpx to re-send the original SSE GET with the Bearer header, and StopAsyncIteration returns that 200 streaming response to aconnect_sse. the retry is present and correct.

[jkgibson-source]

The initial probe is always POST /sse (python-httpx/0.28.1), never GET /sse —
confirmed across all sessions in nginx access logs. This rules out sse_client entirely.

With streamable_http_app() returning 401 (not 405), OAuth now completes in a single
cycle with correct resource binding, but the authenticated POST /sse never arrives
after POST /oauth/token 200. Nginx logs confirm zero requests post-token-exchange.

Screenshot below confirms the server works end-to-end: POST /sse with a valid Bearer
token → HTTP/2 200 + mcp-session-id + SSE response. The missing retry is client-side.

Please test streamable_http_client + OAuthClientProvider specifically — the
sse_client repro passes but doesn't cover the POST-based transport path claude.ai uses.