MCP协议新版四大升级详解上篇：传输机制与安全授权

MCP协议的最新版本（2025-03-26）在传输机制与安全授权领域带来了重要更新。本教程将帮助你深入理解两大核心升级：Streamable HTTP传输模式和OAuth 2.1授权框架，助力开发者快速掌握新特性并将其应用于实际项目中。

01 Streamable HTTP 传输模式

新版本引入了Streamable HTTP远程传输机制，取代了原有的HTTP+SSE模式（本地stdio模式保持不变）。这一改进显著增强了连接的灵活性与稳定性。

1. 背景与动机

原有的HTTP+SSE模式存在一些局限性：服务端需保持长连接、部署较为复杂、中间件兼容性欠佳。随着MCP应用规模的扩大，市场需要一种更灵活、更易扩展的传输方式。

2. 主要变化

新方案的核心在于统一端点与状态管理：

• 服务端只需提供一个统一的HTTP端点（如/messages）即可完成通信。
• 客户端能以完全无状态的方式与服务端交互（采用RESTful HTTP POST方式）。
• 在需要时，客户端可在单次请求中获得SSE响应，例如处理需要进度通知的长时间任务。
• 客户端也可通过HTTP GET建立长连接SSE流，用于接收服务端发送的通知或请求（如Sampling）。
• 增强的会话管理：服务端在初始化时返回Mcp-Session-Id，后续请求需携带该ID。其作用包括：
  • 关联一次会话中的多次交互。
  • 服务端可通过Session-Id终止会话，并要求客户端开启新会话。
  • 客户端也可通过HTTP DELETE请求主动终止会话。

3. 灵活性与健壮性

相较于旧方案，Streamable HTTP具备以下优势：

• 支持无状态服务端：无需依赖长连接，部署更灵活、扩展性更强。
• 中间件兼容性更佳：仅需HTTP支持，无需额外处理SSE。
• 按需启用SSE：保留了SSE的现有优势，可根据实际需求灵活开启。

4. 影响与应用

新版客户端需设置Accept头，支持以下两种返回类型：application/json和text/event-stream。示例如下：

POST /mcp HTTP/1.1
Host: mcp.example.com
Accept: application/json, text/event-stream
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}

如果不要求流式输出，服务端将返回JSON响应；若需要流式模式，则响应头为Content-Type: text/event-stream，通过SSE事件发送一个或多个JSON-RPC消息。

客户端可通过以下方式开启SSE长连接，接收服务端的异步消息推送：

GET /mcp HTTP/1.1
Host: mcp.example.com
Accept: text/event-stream

小提示： 为确保兼容性，需谨慎控制客户端与服务端对连接方式的支持，以适应旧版本对端。具体细节将在SDK升级后解析。

常见问题：

• Q：Streamable HTTP是否向后兼容？
  A：不完全兼容。旧客户端无法理解新传输模式，需升级SDK。但服务端可同时支持旧SSE和新模式，实现逐步过渡。
• Q：无状态模式是否会导致会话管理混乱？
  A：不会。Session-Id机制确保了会话关联，服务端可通过ID准确识别同一客户端。

02 引入基于 OAuth 2.1 的授权框架

MCP 2025-03-26 规范引入了基于OAuth 2.1的授权框架，为基于HTTP交互的客户端与服务端提供了标准化的安全机制。该机制仅适用于远程模式，本地stdio模式无需考虑。

1. 背景与动机

当前多数MCP应用采用本地stdio模式，安全边界较为清晰。但在远程SSE场景中，尤其是第三方MCP共享服务快速增长，缺乏统一的授权机制使得访问权限难以安全管理。引入OAuth 2.1后，资源所有者可通过标准化授权流程控制访问。例如在企业环境中，MCP服务端连接内部数据库或敏感API，通过OAuth授权可确保只有经过用户同意的客户端才能访问，用户可随时撤销令牌以终止访问。此外，开发者能方便地将现有企业身份认证与授权服务整合到MCP服务器中。

2. 角色定义

• 浏览器：用户使用的网络浏览器，用于实现交互式授权。
• MCP客户端（例如智能体、ChatBot）：需要调用MCP服务端功能的应用程序。
• MCP服务端（同时担任OAuth授权服务器）：既是受保护资源的服务器端，也是OAuth认证与授权的服务器。

3. 流程详解

整体授权流程包含以下步骤：

1. 客户端发现授权服务器元数据
   客户端访问标准路径（.well-known/oauth-authorization-server），尝试发现授权端点、令牌端点等元数据。若服务器支持发现，返回标准JSON；若返回404，则客户端按默认配置继续。
2. 动态客户端注册（可选）
   若MCP服务端支持动态客户端注册，客户端无需预先注册，可在运行时注册获得client_id、client_secret等配置。建议在多客户端场景下实现该机制。
3. 准备授权请求（包含PKCE参数）
   PKCE是OAuth 2.1强制要求的保护机制，可有效防范授权码被拦截盗用。包含：
   • code_verifier（随机字符串）
   • code_challenge（基于code_verifier编码生成）
   客户端携带code_challenge获取授权码，随后用code_verifier换取令牌，服务器验证匹配后才发放令牌。
4. 启动浏览器进行用户授权
   客户端打开系统浏览器，跳转到MCP服务端授权地址，带上client_id、redirect_uri、response_type=code、scope、code_challenge等参数。界面会显示授权确认。
5. 用户同意授权
   用户在浏览器中点击“允许授权”（必要时需进行额外验证）。
6. 服务端生成授权码
   服务端验证用户身份与授权请求合法后，生成临时授权码（code）。
7. 授权码回调到客户端
   MCP服务端通过浏览器重定向到客户端提供的redirect_uri，参数附带code=xxx。
8. 客户端接收回调并换取令牌
   客户端捕获回调并获取授权码，然后访问令牌端点，携带code、code_verifier、client_id等参数。服务端验证通过后下发Access Token。
9. 客户端使用令牌调用MCP功能
   令牌在HTTP头中携带：

POST /mcp
Authorization: Bearer {access_token}
Content-Type: application/json

随后即可发起MCP调用，如 tools/call、resources/fetch 等。

4. 影响与应用

• 老版本客户端/服务器若不实现授权，默认仍可在无需认证的环境下通信（授权为可选功能）。
• 规范明确仅在HTTP传输下推荐使用OAuth，本地stdio模式不受影响。
• 不支持OAuth的旧客户端仍可连接不要求认证的新版服务器。若新版服务器开启了授权要求，则客户端需升级以实现OAuth流程。

小提示： 如果你对OAuth流程不熟悉，可以参考文末提供的极简示例代码（此处可放置链接或代码片段）。

常见问题：

• Q：所有MCP服务端都必须实现OAuth吗？
  A：不需要。授权是可选的，只有需要保护资源的场景才需实现。默认情况下，无需认证的客户端仍可正常工作。
• Q：动态客户端注册是否强制？
  A：并非强制，但建议在多客户端场景下实现，以简化客户端管理。
• Q：PKCE参数如何生成？
  A：code_verifier通常为43-128个字符的随机字符串，经SHA256哈希后以Base64URL编码生成code_challenge。具体实现可参考OAuth 2.1规范。

通过以上两大升级，MCP协议在传输灵活性和安全授权方面迈出了重要一步。开发者可根据实际需求选择合适的模式，逐步迁移到新版本，享受更高效、更安全的开发体验。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：MCP协议新版四大升级详解上篇：传输机制与安全授权要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题