MCP峰会3天敲定OAuth 2.1

Python MCP SDK上次更新还是1月24日。68天零版本迭代，TypeScript那边却连发了多个更新——这种落差让用Python写AI工具的人心里没底。4月2日纽约峰会开幕当天，v1.27.0终于推送，同时V2开发状态首次公开。如果你正在用Python搭MCP服务，这次更新直接决定了你接下来半年的代码该怎么写。

v1.27.0的四个补丁，全是V2的"提前剧透"

新版本没搞大动作，但每个改动都指向同一件事：V2分支已经成熟到可以往v1.x回搬功能了。

OAuth资源验证（RFC 8707）是这次的头号更新。它解决的是客户端问题——当你的MCP工具需要访问多个资源服务器时，怎么让令牌带上明确的资源标识。StreamableHTTP会话加了空闲超时，TasksCallCapability从V2分支直接backport，还有主分支的合规测试集成。这些backport不是修bug的权宜之计，是V2功能稳定到能下沉的信号。

换句话说，V2不是PPT状态，是已经跑在main分支上的实时代码。

但别急着切分支。Python V2没有发布时间表，官方口径是"积极开发中"，最早Q3前别指望有能用的release。TypeScript那边倒是快：峰会前一天刚发了v2.0.0-alpha.1和alpha.2，Standard Schema支持、重构的TaskManager、Fastify框架包全上了。Python的V2显然还在pre-alpha，两边进度差着至少一个季度。

OAuth 2.1成为共识：不是新方案，是老标准终于被认真对待

认证轨道六场session的核心信息高度一致——MCP不需要发明新认证协议，把OAuth 2.1用对就行。

Aaron Parecki的session标题定调了："Evolution, Not Revolution"。作为OAuth 2.1 spec作者和Okta身份标准总监，他的立场一直很明确：别在MCP里过度设计认证，标准OAuth 2.1加PKCE，正确实现现有RFC，收工。六场专门讨论这个，不是认证方案还在摇摆，是生态终于统一口径了。

对写代码的人来说，这意味着mcp.server.auth的当前API就是终局形态。v1.27.0里BearerAuth（BearerAuthProvider、BearerAuthBackend）零变动，相关PR没合进去，V2的auth API调整也没宣布。RFC 8707影响的是OAuth客户端侧的资源绑定，你的服务端代码不用动。

如果你这周新开MCP服务项目，现在的mcp.server.auth写法就是V2要标准化的模式——不是临时方案，是未来兼容的基准。

TypeScript先跑半步，Python开发者的实际策略

两边SDK的分化已经很明显。TypeScript的V2 alpha带着Zod v4/Valibot/ArkType的Standard Schema兼容性、全新的Fastify包，架构层面在做减法（废弃方法清理、TaskManager重构）。Python这边还在把V2的功能往v1.x搬运，说明底层结构还在定型。

务实的做法是：继续用v1.27.0的auth模式写新代码，别等V2重构。峰会释放的信号足够清晰——当前API不会被推翻，V2是演进不是革命。OAuth 2.1的共识也意味着认证层不会有颠覆性变化，你可以放心把精力放在业务逻辑上。

那个68天的版本空窗期，现在看像是团队在憋V2的架构定型。v1.27.0的backport策略很聪明：让生产环境的开发者提前用上经过验证的功能，同时给V2主分支争取更多测试时间。

Max Isbey在4月3日的演讲里没给V2时间表，但main分支的活跃度和backport的频率说明一件事——Python V2的代码每天都在跑，只是还没到能贴版本号的程度。对于讨厌踩坑的Python开发者，这其实是好消息：等它正式发布的时候，你迁移的成本会比TypeScript早期采用者低得多。

你现在用mcp.server.auth写的每一行代码，都是在给V2的终局形态做预演——这算是68天等待换来的确定性吗？