Remote MCP (mcp.socket.dev) rejects freshly-issued OAuth access tokens with 401 invalid_token

[clivi-sarboleda]

Summary

The remote Socket MCP server at https://mcp.socket.dev/ rejects access tokens that its own OAuth flow just issued. The token is valid and unexpired — the same token authenticates successfully against api.socket.dev — but every MCP request returns 401 invalid_token. This makes the remote MCP server unusable with OAuth-capable MCP clients (tested with Claude Code).

Environment

• Client: Claude Code (streamable HTTP MCP client with OAuth + dynamic client registration)
• Server: https://mcp.socket.dev/
• Account: Socket org clivi (team plan), reproduced consistently across 2 days (2026-06-09 and 2026-06-10)

Steps to reproduce

1. Add the remote server per the docs: claude mcp add --transport http socket-mcp https://mcp.socket.dev/
2. Complete the OAuth flow (DCR client, e.g. client_id=dcr-f8TfK-9JQzUGucp7lDJCymIp, scope packages:list, resource=https://mcp.socket.dev/). The browser flow finishes with "Authentication successful".
3. Client receives and stores an access token (sktsec_…, 55 chars, ~15-minute TTL) plus a refresh token.
4. Immediately (>10 minutes before expiry) call the MCP endpoint with the token:

curl -X POST https://mcp.socket.dev/ \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"diag","version":"1.0"}}}'

Expected

200 with an initialize result.

Actual

HTTP/2 401
www-authenticate: Bearer error="invalid_token", error_description="Invalid or expired token", resource_metadata="https://mcp.socket.dev/.well-known/oauth-protected-resource"
{"error":"invalid_token","error_description":"Invalid or expired token"}

Evidence the token itself is valid

The exact same token, at the same moment, works against the regular API:

curl https://api.socket.dev/v0/organizations -H "Authorization: Bearer $ACCESS_TOKEN"
# 200 — returns the org as expected

So issuance, scope (packages:list, which matches the resource metadata's scopes_supported), audience/resource binding, and storage are all fine — only the MCP resource server's token validation fails.

Additional observations

• The Remote Socket MCP docs say "No API key or authentication required!" — but unauthenticated requests get 401 with error_description="Missing Authorization header". If auth is now required, the docs are stale; if it isn't, the 401s are the bug.
• https://mcp.socket.dev/mcp (referenced in the Windsurf section of those docs) returns 404.
• Workaround that works fine: local stdio server (@socketsecurity/mcp) with a static API key of the same packages:list scope. (Side note: its engines field requires npm ≥ 11.16, which no current Node release bundles — npx fails out of the box; pnpm dlx works.)

[Brettclark1]

Independent reproduction, corroborating everything above — different account (free-plan org), different machine, same result, 2026-06-12.

Same-second control: an access token freshly minted by the api.socket.dev OAuth flow returns 200 from GET https://api.socket.dev/v0/organizations (correct org) and 401 {"error":"invalid_token","error_description":"Invalid or expired token"} from POST https://mcp.socket.dev/ (initialize) within the same second. Clock skew vs the server Date header: zero.

Additional data point — it's not the grant type or the client: I reproduced with a hand-rolled client entirely outside any MCP client implementation: fresh dynamic client registration (201), PKCE authorization-code flow, resource=https://mcp.socket.dev/ (RFC 8707) sent on both the authorize and token requests, scope packages:list (matching the resource's /.well-known/oauth-protected-resource scopes_supported). Tokens minted via authorization_code and via refresh_token grants are both rejected identically, so this isn't client-specific (reproduced with both Claude Code and raw HTTP) and isn't refresh-rotation related.

Two smaller observations while diagnosing:

• The Cloudflare zone in front of mcp.socket.dev bans some non-browser user-agents outright — Python-urllib/3.x gets 403 CF error 1010 (browser_signature_banned) before reaching the origin, while curl/8.x, browser UAs, and MCP-client UAs pass through to the origin's 401. Worth knowing for anyone else debugging this, since it masquerades as a different failure.
• Confirming the doc mismatches noted above: unauthenticated requests get 401 Missing Authorization header despite the "no authentication required" language, and https://mcp.socket.dev/mcp returns 404.

Net: the authorization server issues tokens it honors itself, but the MCP resource server's validation rejects them — looks like the RS is validating against the wrong store or with broken introspection credentials.

[jdalton]

Fixed and deployed. The hosted server's OAuth handling was stabilized — the public origin now exposes the authorization-server metadata correctly, and the dynamic-client (DCR) token/refresh flow no longer rejects freshly-issued tokens, which is what this issue hit.

The fix went out on 2026-06-10. A fresh OAuth login against https://mcp.socket.dev/ should now work — please re-run claude mcp add --transport http socket-mcp https://mcp.socket.dev/, complete the flow, and reopen if you still get 401 invalid_token.

The two doc nits (the stale "no authentication required" wording and the /mcp 404) are tracked separately.

[Brettclark1]

Reopening per your instruction — a clean-process OAuth login against https://mcp.socket.dev/ still returns 401 on freshly-issued tokens after the 2026-06-10 deploy. This is the first reproduction following the production fix.

Conditions (the clean-room precondition this needed): a freshly-launched MCP client process in a brand-new terminal, no inherited in-memory OAuth state, and the prior Keychain token entry cleared beforehand. So nothing stale could mask a real fix — every token below was minted fresh by the post-fix authorization server.

What happened — first-party MCP client (claude-code/2.1.177), not a hand-rolled repro:

1. Full OAuth 2.1 + DCR flow completed against https://api.socket.dev (fresh dynamic public client, PKCE, resource=https://mcp.socket.dev/, scope packages:list). Authorization-code grant succeeded; token persisted.
2. The freshly-issued access token was valid on its face: length 55, refresh token present, ~900s TTL — exactly as issued by the AS this run.
3. The first authenticated request to the MCP resource server https://mcp.socket.dev/ was rejected.

Client transport log (UTC 2026-06-13T04:56:45, ~2h after this issue was closed), secrets elided:

HTTP transport options: {"url":"https://mcp.socket.dev/","headers":{"User-Agent":"claude-code/2.1.177 (sdk-cli)"},"hasAuthProvider":true,"timeoutMs":60000}
Returning tokens  →  Token length: 55  |  Has refresh token: true  |  Expires in: 886s
Saving tokens     →  Token expires in: 900  |  Has refresh token: true
HTTP Connection failed after 666ms: Streamable HTTP error: Server returned 401 after successful authentication (code: 401, errno: none)
Authentication required for HTTP server

The client then reverted to Needs authentication, i.e. the resource server rejected a token its own authorization server issued seconds earlier — the same signature as the original report.

Already established earlier in this thread (2026-06-12), so not re-litigating here: the same-second control (identical fresh token → 200 from GET api.socket.dev/v0/organizations, 401 {"error":"invalid_token","error_description":"Invalid or expired token"} from mcp.socket.dev/), zero clock skew, and client-independence (raw hand-rolled PKCE client failing identically to the MCP client). What's new tonight is only the decisive part: a clean, post-fix login still 401s, which rules out stale local state as the explanation.

Net: the AS still issues tokens the RS won't honor on the public origin. The DCR token/refresh path called out as fixed appears to still be the failing path. Happy to capture a raw initialize request/response pair with full headers if that's useful for the RS-side introspection logs.

[Brettclark1]

John-David Dalton (@jdalton) — requesting reopen (I don't have reopen permission on this repo). A clean-process OAuth login against https://mcp.socket.dev/ still returns 401 on freshly-issued tokens after the 2026-06-10 deploy. This is the first reproduction following the production fix.

Conditions (the clean-room precondition this needed): a freshly-launched MCP client process in a brand-new terminal, no inherited in-memory OAuth state, and the prior Keychain token entry cleared beforehand. So nothing stale could mask a real fix — every token below was minted fresh by the post-fix authorization server.

What happened — first-party MCP client (claude-code/2.1.177), not a hand-rolled repro:

1. Full OAuth 2.1 + DCR flow completed against https://api.socket.dev (fresh dynamic public client, PKCE, resource=https://mcp.socket.dev/, scope packages:list). Authorization-code grant succeeded; token persisted.
2. The freshly-issued access token was valid on its face: length 55, refresh token present, ~900s TTL — exactly as issued by the AS this run.
3. The first authenticated request to the MCP resource server https://mcp.socket.dev/ was rejected.

Client transport log (UTC 2026-06-13T04:56:45, ~2h after this issue was closed), secrets elided:

HTTP transport options: {"url":"https://mcp.socket.dev/","headers":{"User-Agent":"claude-code/2.1.177 (sdk-cli)"},"hasAuthProvider":true,"timeoutMs":60000}
Returning tokens  →  Token length: 55  |  Has refresh token: true  |  Expires in: 886s
Saving tokens     →  Token expires in: 900  |  Has refresh token: true
HTTP Connection failed after 666ms: Streamable HTTP error: Server returned 401 after successful authentication (code: 401, errno: none)
Authentication required for HTTP server

The client then reverted to Needs authentication, i.e. the resource server rejected a token its own authorization server issued seconds earlier — the same signature as the original report.

Already established earlier in this thread (2026-06-12), so not re-litigating here: the same-second control (identical fresh token → 200 from GET api.socket.dev/v0/organizations, 401 {"error":"invalid_token","error_description":"Invalid or expired token"} from mcp.socket.dev/), zero clock skew, and client-independence (raw hand-rolled PKCE client failing identically to the MCP client). What's new tonight is only the decisive part: a clean, post-fix login still 401s, which rules out stale local state as the explanation.

Net: the AS still issues tokens the RS won't honor on the public origin. The DCR token/refresh path called out as fixed appears to still be the failing path. Happy to capture a raw initialize request/response pair with full headers if that's useful for the RS-side introspection logs.

[jdalton]

Reopened — thanks for the clean-room reproduction (fresh process, cleared keychain, post-deploy). That rules out stale local state, so my earlier close was premature: the #21195 fix did not resolve the resource-server rejection on the public origin. Same-second control (token 200 on api.socket.dev, 401 invalid_token on mcp.socket.dev) points squarely at the RS-side token validation, not the client or the AS issuance. Digging into the introspection path now; a raw initialize request/response pair with full headers would help correlate against the RS introspection logs if you can capture one.

[Brettclark1]

John-David Dalton (@jdalton) — a correction so the record's accurate before you wait on wire-level data from us.

The transport log in my earlier comment was the Claude Code client-level log (transport options, token length/TTL, and the "401 after successful authentication" result) — not a raw wire-level request/response pair. I offered the raw initialize pair with full headers as a follow-up, but it wasn't captured during that clean-room run, so I don't have it to hand over.

One detail from our existing record may still help the introspection-path question: the 401 we captured from the MCP endpoint on 2026-06-12 came back with no WWW-Authenticate header present — only the JSON body {"error":"invalid_token","error_description":"Invalid or expired token"}. So the full WWW-Authenticate header you asked us to preserve may not exist on the MCP 401 at all, and that absence — a bare invalid_token with no Bearer challenge — may itself be diagnostic for the resource-server token-validation path.

I'm not in a position to re-run the clean-room wire capture right now, so please don't hold for that data from us. If that changes, I'll capture it properly and post the redacted pair.