为什么 MCP 需要 OAuth 2.1？

授权问题：Server 如何验证用户身份？

想象这样一个场景：

你在使用一个 GitHub MCP Server，让 AI 帮你创建 Issue。但 Server 怎么知道你是谁？你有权限访问哪个仓库？

传统方案的困境：

方案 1：硬编码 API Key

{
  "mcpServers": {
    "github": {
      "command": "github-mcp-server",
      "args": ["--token", "ghp_xxxxxxxxxxxxxx"]
    }
  }
}

问题：

• 每个 Server 都需要单独配置 Token
• Token 无法安全存储和轮换
• 无法实现细粒度权限控制

方案 2：配置文件传递

{
  "mcpServers": {
    "github": {
      "env": {
        "GITHUB_TOKEN": "从环境变量读取"
      }
    }
  }
}

问题：

• 仍然需要手动配置每个 Server
• 跨机器同步困难
• 企业级场景不可行

OAuth 2.1 的解决方案：

通过统一的授权流程，Server 可以验证用户身份并获得适当权限——用户只需要授权一次，Client 负责管理 Token 的生命周期。

企业级安全需求

企业级场景需要更强的安全保证：

OAuth 2.1 核心要点

什么是 OAuth 2.1？

OAuth 2.1 是 OAuth 2.0 的下一代规范，简化了 OAuth 2.0 的复杂性，同时增强了安全性。

核心改进：

• 强制使用 PKCE（Proof Key for Code Exchange）
• 移除隐式授权流程
• 强制使用 Token 绑定
• 简化刷新 Token 机制

PKCE：防止授权码拦截攻击

传统 OAuth 2.0 的问题：

1. Client 请求授权
   ↓
2. 授权服务器返回授权码
   ↓
3. 攻击者拦截授权码（中间人攻击）
   ↓
4. 攻击者用授权码换取 Access Token

PKCE 的解决方案：

1. Client 生成 code_verifier 和 code_challenge
   code_verifier = 随机字符串
   code_challenge = SHA256(code_verifier)
   ↓
2. Client 请求授权，携带 code_challenge
   ↓
3. 授权服务器返回授权码（与 code_challenge 绑定）
   ↓
4. Client 用授权码 + code_verifier 换取 Access Token
   ↓
5. 授权服务器验证 code_verifier 是否匹配 code_challenge
   ✓ 验证通过，返回 Access Token
   ✗ 验证失败，拦截者没有 code_verifier

PKCE 流程示例：