Claude Cowork · MCP 认证架构

Cowork 真实架构 · 本地 VM + 云端 LLM 混合模型

💻 本地（你的电脑）

Claude Desktop App

Cowork UI · 用户交互入口

🐧 Linux 沙箱 VM

macOS: Apple Virtualization · Win: Hyper-V

bubblewrap + seccomp 隔离

文件挂载，不复制出机器

本地 stdio MCP（可选）

环境变量传凭据 · OS Keychain 存储

API 调用

⇄

☁️ Anthropic 云端

🧠 LLM 推理

claude-sonnet / opus · 推理在云端

🔐 Token Store（云端 KMS）

MCP OAuth Token 存储在这里

key = Anthropic_ID + Connector_ID

远程 MCP Server

Slack / Gmail / 第三方 HTTPS 端点

⚠️ 之前的表述有误：Cowork 不是纯云端产品。执行沙箱在本地 VM，文件不出本机；但 LLM 推理和 MCP OAuth Token 管理在 Anthropic 云端。这是「本地执行 + 云端智能」的混合架构。

🏢

Anthropic 云端 Token Store

oauth_anthropic_creds（官方 Connector）

Slack、Gmail 等官方 Connector 的 OAuth Token 存这里。Anthropic 持有 client_secret，代理完成 token exchange，Token 绑定你的 Claude 账号 ID，跨 Desktop / Cowork / Web 共用。

Slack · Gmail · GitHub · Jira

☁️

Anthropic 云端 Token Store

oauth_dcr / oauth_cimd（第三方远程 MCP）

第三方自建 Remote MCP 的 Token 也存云端。OAuth flow 由 claude.ai 代理，Access Token + Refresh Token 加密存储，不落本地磁盘，但与上面共用同一套 Token Store 基础设施。

第三方 HTTPS MCP Server

💻

本地 OS Keychain / 环境变量

stdio MCP · Desktop Extension

在本地 VM 内运行的 stdio MCP，凭据通过环境变量注入或存储在 macOS Keychain / Windows Credential Store，完全不经过 Anthropic 服务器。这是 Cowork 里唯一真正的「本地 KMS」。

本地进程 · 系统级访问

🔑 修正后的关键结论

→Cowork = 本地沙箱 VM（执行）+ Anthropic 云端（LLM 推理 + Token 管理），不是纯云端，也不是纯本地。

→MCP OAuth Token（Slack/Gmail 等）存在 Anthropic 云端 Token Store，以 Anthropic_ID + Connector_ID 为复合主键，不在本地 VM 内。

→本地 stdio MCP 的凭据（API Key 等）存在 本地 OS Keychain / 环境变量，文件操作在沙箱内完成，数据不出本机。

→纯机器间 client_credentials grant 不支持，每次 OAuth 连接必须有用户 consent 步骤。

Cowork (本地桌面) + 三方 Remote MCP (e.g. Slack) · 首次连接认证流程

👤
用户

本地 Desktop App

🐧
本地
沙箱 VM

Linux VM · 执行层

☁️
Anthropic
云端后端

LLM 推理 · 编排

🔐
Token
Store

Anthropic 云端 KMS

🔧
Slack
MCP

远程 HTTPS 端点

🏛️
Slack
OAuth

slack.com/oauth

Phase 1 · 发起 & 凭据检索

1

用户在 Cowork Desktop 发起指令，本地 VM 接收任务，发送至 Anthropic 云端 LLM 推理

用户 → 本地 VM → Anthropic 云端 API → LLM tool_use 声明

2

Anthropic 云端后端查询 Token Store：该 Anthropic_ID 是否有 Slack 的有效 Token？

key = Anthropic_Account_ID + connector_id("slack")

Phase 2A · 首次授权（Token 为空）

3

Token Store 返回空 → 云端编排层通知本地 Desktop，弹出「连接 Slack」授权卡片

LLM 推理挂起 · Desktop 弹出系统级授权弹窗

4

用户点击授权，系统浏览器跳转 Slack OAuth consent screen

redirect_uri = https://claude.ai/api/mcp/auth_callback

5

Slack 验证通过，发放 Authorization Code，回调至 claude.ai（云端）

OAuth 2.1 + PKCE · code=xxx → Anthropic 云端接收

6

Anthropic 云端用持有的 client_secret 向 Slack 换取 Access Token + Refresh Token

oauth_anthropic_creds 模式 · Token 不经过本地 VM

7

Token 加密存入 Anthropic 云端 Token Store，绑定用户 Anthropic_ID + Slack Connector

云端 KMS 写入 · AES-256 · 按账号隔离 · 不落本地磁盘

Phase 2B · 后续复用（Token 已有）

✓

Token Store 直接返回有效 Token，跳过授权步骤，用户无感知

云端后台静默取 Token · 本地 VM 继续执行任务

Phase 3 · 工具调用执行

8

Anthropic 云端携带 Bearer Token 调用 Slack Remote MCP Server（HTTPS）

Authorization: Bearer {access_token} · 云端发起，不经本地 VM

9

Slack MCP 校验 Token，执行操作，返回 JSON 结果至 Anthropic 云端

MCP Server 验签 → 调用 Slack API → JSON 结果

10

结果返回 LLM，恢复推理，最终答复经云端下发至本地 VM，展示给用户

tool_result → LLM → 自然语言回复 → 本地 Desktop 展示

⚡ Token 刷新机制

→若 Access Token 过期，Cowork 后端自动用 Refresh Token 静默续期，用户无需重新授权。

→若 Refresh Token 也过期（Slack 通常 60 天），才会重新触发 consent screen。

MCP 类型	Token 存储位置	Auth 模式	OAuth Client 持有者	用户需感知?	回调 URL
Slack / Gmail / GitHub 官方目录 Connector	Anthropic 云端	oauth_anthropic_creds	Anthropic 持有 client_secret	仅首次	claude.ai/api/mcp/auth_callback
第三方 Remote MCP 自建 HTTPS 端点	Anthropic 云端	oauth_dcr / oauth_cimd	动态注册 / CIMD（Client 自描述）	仅首次	claude.ai/api/mcp/auth_callback
本地 stdio MCP Claude Desktop / Code	本地 OS Keychain	环境变量 / 静态 Bearer	用户自持 API Key	配置时手动填写	N/A（本地进程）
Desktop Extension (MCPB) Claude Desktop 扩展包	本地 OS Keychain	混合（可含 OAuth）	扩展包自定义	看扩展实现	RFC 8252 loopback
Claude Code MCP CLI 原生客户端	本地（ephemeral）	oauth_dcr / oauth_cimd	动态注册	仅首次	http://localhost:{port}/callback

🚫 不支持的模式

✗纯机器间 client_credentials grant：没有用户 in the loop 的 M2M Token 不支持，必须有 consent screen。

✗URL 中的 query 参数传 Token：如 ?token=xxx、?apiKey=xxx，MCP 规范明确禁止。

✗静态 Bearer 粘贴（static_bearer）：目前尚未支持，即将推出。

✓所有远程 Connector 必须实现 Protected Resource Metadata（/.well-known/oauth-protected-resource），让 Claude 自动发现授权服务器。

Claude Cowork · MCP 认证架构解析