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. 流程详解
整体授权流程包含以下步骤：
- 客户端发现授权服务器元数据
客户端访问标准路径（.well-known/oauth-authorization-server），尝试发现授权端点、令牌端点等元数据。若服务器支持发现，返回标准JSON；若返回404，则客户端按默认配置继续。 - 动态客户端注册（可选）
若MCP服务端支持动态客户端注册，客户端无需预先注册，可在运行时注册获得client_id、client_secret等配置。建议在多客户端场景下实现该机制。 - 准备授权请求（包含PKCE参数）
PKCE是OAuth 2.1强制要求的保护机制，可有效防范授权码被拦截盗用。包含：code_verifier（随机字符串）code_challenge（基于code_verifier编码生成）
code_challenge获取授权码，随后用code_verifier换取令牌，服务器验证匹配后才发放令牌。 - 启动浏览器进行用户授权
客户端打开系统浏览器，跳转到MCP服务端授权地址，带上client_id、redirect_uri、response_type=code、scope、code_challenge等参数。界面会显示授权确认。 - 用户同意授权
用户在浏览器中点击“允许授权”（必要时需进行额外验证）。 - 服务端生成授权码
服务端验证用户身份与授权请求合法后，生成临时授权码（code）。 - 授权码回调到客户端
MCP服务端通过浏览器重定向到客户端提供的redirect_uri，参数附带code=xxx。 - 客户端接收回调并换取令牌
客户端捕获回调并获取授权码，然后访问令牌端点，携带code、code_verifier、client_id等参数。服务端验证通过后下发Access Token。 - 客户端使用令牌调用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协议在传输灵活性和安全授权方面迈出了重要一步。开发者可根据实际需求选择合适的模式，逐步迁移到新版本，享受更高效、更安全的开发体验。