• 状态（Status）: Final
• 类型（Type）: Standards Track
• 创建（Created）: 2025-07-22
• 作者（Author(s)）: Nate Barbettini (@nbarbettini) and Wils Dawson (@wdawson)
• Issue: #1036

​

摘要

​

动机

1. 敏感数据收集：API 密钥、密码和其他凭据绝不能经过中间系统传输。
2. 外部授权：MCP 服务器常常需要代表用户访问第三方 API。MCP 授权规范只涵盖客户端到服务器的授权，不涵盖服务器到第三方的授权。安全最佳实践文档明确禁止令牌透传（token passthrough），需要一种用于外部（第三方）OAuth 流的安全机制。这是从 #234 和 #284 讨论中浮现的一个特别重要的驱动因素。
3. 支付和订阅流：金融交易需要 PCI 合规和安全的支付处理，这无法通过带内数据收集实现。

​

规范

​

概览

• 表单模式（form mode，带内）：服务器可以用可选的 JSON schema 从用户处请求结构化数据以校验响应（此处无变化，除了为既有能力添加一个名称）
• URL 模式（url mode，带外）：服务器可以将用户引导至外部 URL，以进行不得经过 MCP 客户端的敏感交互

​

能力

{
  "capabilities": {
    "elicitation": {
      "form": {},
      "url": {}
    }
  }
}

{
  "capabilities": {
    "elicitation": {},
  },
}

​

表单征询请求

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "elicitation/create",
  "params": {
    "mode": "form", // New field
    "message": "Please provide your GitHub username",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "name": {
          "type": "string"
        }
      },
      "required": ["name"]
    }
  }
}

​

URL 征询请求

​

示例：OAuth 授权流

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "elicitation/create",
  "params": {
    "mode": "url",
    "elicitationId": "550e8400-e29b-41d4-a716-446655440000",
    "url": "https://github.com/login/oauth/authorize?client_id=abc123&state=xyz789&scope=repo",
    "message": "Please authorize access to your GitHub repositories to continue."
  }
}

​

响应动作

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "action": "accept" // or "decline" or "cancel"
  }
}

​

完成通知

• 该通知**必须（MUST）**只发送给发起该征询请求的客户端。
• 该通知**必须（MUST）**包含在原始 elicitation/create 请求中确立的 elicitationId。
• 客户端**必须（MUST）**忽略引用未知或已完成 ID 的通知。
• 如果完成通知始终未到达，客户端**应当（SHOULD）**为用户提供一种手动继续交互的方式。

{
  "jsonrpc": "2.0",
  "method": "notifications/elicitation/complete",
  "params": {
    "elicitationId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

​

URL 征询必需错误

{
  "jsonrpc": "2.0",
  "id": 2,
  "error": {
    "code": -32042,
    "message": "This request requires more information.",
    "data": {
      "elicitations": [
        {
          "mode": "url",
          "elicitationId": "550e8400-e29b-41d4-a716-446655440000",
          "url": "https://oauth.example.com/authorize?client_id=abc123&response_type=code&...",
          "message": "Authorization is required to access your Example Co files."
        }
      ]
    }
  }
}

​

理由

​

设计决策

1. 两种机制服务于相同的根本目的：从用户处收集信息
2. 为相同目的设置两个相似但独立的机制令人困惑且易出错
3. mode 参数干净地分离了两种交互模式

• 如果 MCP 客户端从第三方授权服务器获取用户令牌，MCP 服务器就会成为一个令牌透传服务器，这是明确禁止的。
• 类似地，对于支付类流，MCP 客户端需要执行 PCI 合规的支付处理，这不是对 MCP 客户端所期望的要求。

​

所考虑的替代方案

1. 令牌透传：仅仅将 MCP 客户端的令牌传递给外部服务，因《安全最佳实践》中记录的安全关切而被否决。让 MCP 客户端获取额外令牌并将其传递给 MCP 服务器，出于相同原因被否决。
2. OAuth 专用能力：曾考虑为使用 OAuth 的外部（第三方）授权创建一个专用能力，但被否决，转而采用支持多种用例的更通用的 URL 模式征询方式。

​

社区反馈

• 无客户端暴露的安全凭据收集
• 独立于 MCP 授权的外部授权模式
• 支付和订阅流支持
• 清晰的安全边界和信任模型

​

向后兼容性

1. 能力声明：客户端现在必须指定其支持哪些征询模式：
   {
     "capabilities": {
       "elicitation": {
         "form": {},
         "url": {}
       }
     }
   }
   
   此前，客户端只声明 "elicitation": {}，不带模式说明。
2. Mode 参数：所有 elicitation/create 请求现在都必须包含一个 mode 参数（"form" 或 "url"）。

​

迁移路径

• 服务器**应当（SHOULD）**在发送模式特定请求之前检查客户端能力
• 客户端**可以（MAY）**初期只支持表单模式以保持兼容
• 既有的表单征询实现在添加 mode 参数后继续工作

​

参考实现

​

安全影响

​

URL 安全要求

1. SSRF 防范：客户端必须验证 URL 以防止服务器端请求伪造攻击
2. 协议限制：URL 征询仅允许 HTTPS URL
3. 域名验证：客户端必须向用户清晰显示目标域名

​

信任边界

• MCP 客户端绝不会看到 MCP 服务器经由 URL 征询获取的敏感数据
• MCP 服务器必须独立验证用户身份
• 第三方服务通过安全的浏览器上下文直接与用户交互

​

身份验证

​

实现要求

1. 客户端必须：
   • 使用防止检视用户输入的安全浏览器上下文
   • 为 SSRF 防护验证 URL
   • 在打开 URL 之前获得明确的用户同意
   • 清晰显示目标域名
2. 服务器必须：
   • 将征询状态绑定到已认证的用户会话
   • 在 URL 征询流的开始和结束验证用户身份
   • 实施适当的限速
3. 双方应当：
   • 出于审计目的记录安全事件
   • 为征询请求实现超时机制
   • 为安全失败提供清晰的错误消息

​

与既有安全措施的关系

• 在既有 MCP 授权框架内工作（MCP 授权不受本提案影响）
• 遵循关于令牌处理的《安全最佳实践》
• 保持客户端-服务器授权与服务器-第三方授权之间的关注点分离