@modelcontextprotocol/core@2.1.0
MCP TypeScript SDK 发布 @modelcontextprotocol/core@2.1.0，新增 DPoP（RFC 9449 / SEP-1932）发送方约束访问令牌支持。客户端通过实现 OAuthClientProvider.dpop() 返回 DpopSession 来启用，并新增 generateDpopKeyPair、accessTokenHash、isDpopNonceChallenge。auth()、exchangeAuthorization、refreshAuthorization、fetchToken 会在令牌请求中签名 DPoP proof，遇到授权服务器 use_dpop_nonce 挑战时重试一次并重新应用客户端认证。
发展脉络
- 首次出现@modelcontextprotocol/core@2.1.0MCP TypeScript SDK Releases
- 当前判断MCP 生态在 OAuth 之上补齐发送方约束令牌，反映 Agent 工具调用链路对令牌泄露与重放的防护需求上升。判断：这可能推动 MCP 服务端与客户端在认证能力上分层，但当前证据仅覆盖 TypeScript SDK 客户端一侧，尚不能推断其他语言 SDK 或托管服务的跟进节奏。Agent Pulse · 分析
@modelcontextprotocol/core@2.1.0 为 MCP TypeScript SDK 客户端引入 DPoP（RFC 9449 / SEP-1932）发送方约束访问令牌。启用方式是实现 OAuthClientProvider.dpop() 返回 DpopSession，配套新增 generateDpopKeyPair、accessTokenHash、isDpopNonceChallenge。令牌请求会携带 DPoP proof，遇到授权服务器 use_dpop_nonce 挑战时重试一次并重新应用客户端认证。StreamableHTTPClientTransport、SSEClientTransport 与 withOAuth 会以 Authorization: DPoP 加每请求新 proof 的方式呈现 token_type 为 DPoP 的访问令牌，遇到资源服务器 use_dpop_nonce 挑战重试一次，并接收任意响应上的 DPoP-Nonce；授权服务器签发的 Bearer 令牌仍按 Bearer 呈现。DPoP 在 fetch 层生效，传输层用 withDpopFromProvider(provider) 中间件包装资源服务器 fetch，proof 绑定到实际发出的请求；withDpop(session, getToken) 也对外导出。
从描述看，DPoP 被放在 fetch 中间件层而非业务层，意味着 proof 与真实发出的请求绑定，减少令牌被重放的可能；nonce 挑战重试与客户端认证逐次重放是需要注意的实现细节。可验证下一信号：SDK 是否补充 DPoP 相关测试、文档或示例，以及服务端实现是否声明支持 SEP-1932。
MCP 生态在 OAuth 之上补齐发送方约束令牌，反映 Agent 工具调用链路对令牌泄露与重放的防护需求上升。判断：这可能推动 MCP 服务端与客户端在认证能力上分层，但当前证据仅覆盖 TypeScript SDK 客户端一侧，尚不能推断其他语言 SDK 或托管服务的跟进节奏。
对使用 MCP 连接外部工具的企业，DPoP 提供了比 Bearer 更强的令牌绑定选项，可能降低凭证泄露风险；但启用需要客户端实现 dpop() 并管理密钥，短期会增加集成成本。可验证下一信号：是否有生产级 MCP 服务端明确要求或推荐 DPoP。
若 DPoP 在 MCP 客户端与服务端同时落地，令牌窃取后的可用性会下降，但会引入密钥管理与 nonce 处理的运维复杂度。可验证下一信号：其他 MCP SDK 或主流 MCP 服务端是否发布对应支持说明。