Local vs remote MCP servers: how each connects, step by step

说明与用途

作者研究了本地和远程 MCP 服务器如何建立连接并处理身份验证，详细说明了本地服务器的生命周期、带 PKCE 的 OAuth 流程以及令牌存储。

问题

Understanding the differences in how local and remote MCP servers establish connections and handle authentication for AI tool calls.

结果

The author confirmed that local MCP servers run as child processes, reuse across calls, and terminate with the session, sourcing credentials from environment variables. Remote MCP servers use OAuth with PKCE, store tokens locally, and validate tokens per spec, with opaque tokens for the tested services.

工作流

• Start Claude Code session
• Claude launches local MCP server as child process
• Reuse server for subsequent tool calls
• Stop server when session ends
• Observe server termination after crash
• For remote servers: send request without token → 401
• Read www‑authenticate header → sign‑in server URL
• Fetch sign‑in server public file → login and token URLs
• Claude identifies itself with client ID URL
• Generate PKCE verifier and challenge
• Open browser to sign‑in server login page with PKCE challenge
• User logs in, receives one‑time code via callback
• Claude exchanges code + verifier for access and refresh tokens
• Store tokens in ~/.claude/.credentials.json
• Use access token on every subsequent request
• Refresh token when access token expires
• Revoke tokens via sign‑in server revocation endpoint

证据

A session that called the tool twice started the server once.

来源

Claude stops the server before exiting itself.

来源

The spec says local (stdio) servers should take credentials from the environment instead of using OAuth.

来源

Claude sends the code plus the verifier from step 5. The sign‑in server hashes the verifier and compares it with the challenge from step 6.

来源

On my machine they're in ~/.claude/.credentials.json, an owner‑only file, with fields for each server: accessToken, refreshToken, expiresAt, clientId, issuer.

来源