feat(mcp-client): OAuth 2.0 support for streamable-http servers (auto-refresh instead of static headers)

[vkpeter]

DeepSeek Harness: OAuth 2.0 support for mcp-client (klaar om in te dienen)

Repo: deepseek-ai/deepseek-harness · branch: feat/mcp-client-oauth op fork vkpeter/deepseek-harness (commit 2220dee)
Compare: master...vkpeter:feat/mcp-client-oauth

Status 3 sep 2026: PR's van forks en issues zijn door de repo-eigenaars
uitgeschakeld (has_issues: false, has_pull_requests: false, gemeten via de
GitHub-API). Discussions staan aan. Deze tekst dient als discussion in de
categorie Ideas (zoals discussion 5431 voor de nl-locale op 2 sep 2026).

Titel

feat(mcp-client): OAuth 2.0 support for streamable-http servers (auto-refresh instead of static headers)

Body

@deepseek-ai/dsh-mcp-client can only attach static Authorization headers
(requestInit.headers) and contains no OAuth logic: no RFC 8414 discovery, no
PKCE, no token refresh, no 401 handling. For MCP servers with short-lived
access tokens (measured: 1 h on Supabase OAuth-backed servers) this means the
tools go unauthorized after expiry, are missing from new sessions, and the
user must refresh tokens externally and rewrite the client config; with
single-use (rotating) refresh tokens two overlapping refreshes force a full
re-login. Claude Code/Desktop do not have this problem because their MCP
client runs the full OAuth flow after a one-time pairing.

The change is complete and ready to merge: branch feat/mcp-client-oauth on
fork vkpeter/deepseek-harness (commit 2220dee). PRs from forks are disabled
on this repo, hence this note.

What the branch does (packages/mcp/mcp-client only):

• Optional oauth config on the streamable-http variant
  (oauth.tokenStorePath, oauth.authorizationServerUrl), mutually
  exclusive with a static bearer headers.Authorization.
• New src/oauth-provider.ts: an OAuthClientProvider that reads/writes a
  JSON token store (default ~/.dsh/mcp-oauth.json, one entry per
  serverName: access_token, refresh_token, client_id, token_endpoint) and
  restores discovery state out-of-band when authorizationServerUrl is set
  (for servers whose RFC 8414 discovery document lives under a different
  path than the MCP endpoint, e.g. Supabase at <ref>.supabase.co/auth/v1).
• createTransport hands the SDK's StreamableHTTPClientTransport the
  provider when oauth is set. The SDK (already a dependency, v1.30) then
  attaches the stored access token, and on a 401 runs its built-in auth()
  flow: refresh via the stored refresh token, persist the rotated tokens,
  retry. No new dependencies.
• The interactive first-time consent flow is intentionally not hosted inside
  the plugin (needs a local redirect listener); redirectToAuthorization
  fails with an actionable error pointing at the out-of-band login.

Verification (measured locally against a Supabase-hosted MCP server, SDK
1.30.0, client 0.1.1-rc.2 patched):

• connect + tools/list with a stored token: OK (13 tools)
• forced 401 (dummy access token) -> automatic refresh via the stored
  refresh token -> tools/list OK again, rotated refresh token persisted

Motivation: makes short-lived OAuth access tokens work without external
refresh scripts, matching the behavior Claude Code users get for free.