Vercel向长期静态凭证宣战：OIDC如何重塑机器身份认证

十五年前，TLS 还只是用来保护应用中最敏感区域的手段。后来，Google、Let's Encrypt、EFF 等推动 HTTPS 无处不在，加密成了每个请求的默认选项。如今，机器对机器的身份认证正处在类似的转折点上。Vercel 最近发文宣布，将推动 OIDC（OpenID Connect）成为其平台及 Marketplace 集成中的默认认证方式，并给不支持安全认证的供应商设定了明确的淘汰时间表。这不仅是 Vercel 的产品决策，更可能成为整个行业从静态密钥向动态身份令牌迁移的信号。

长期静态凭证为什么不可持续

长期静态凭证指的是 API 密钥、数据库密码这类应用反复使用、通常没有过期时间的机密信息。Vercel 在文中指出，随着 AI 代理承担越来越多的工作，我们通过凭证赋予它们访问系统、工具和数据的权限，而这些权限往往远超当前任务所需。

凭证泄露的途径很多：可能被提交到代码仓库或聊天记录中，可能在服务或依赖被攻破时被窃取，也可能因为提示注入导致代理主动泄露。一旦泄露，攻击者就能在凭证过期或被撤销前一直使用它。Vercel 坦言，公司曾多次因为谨慎而花费数千工程小时进行密钥轮换，过程非常痛苦，他们再也不想重来一次。

这引出一个关键认知：静态加密不足以应对生产环境中的凭证窃取。当恶意代码能够读取应用在生产环境中的凭证时，加密存储并不能阻止它被滥用。

OIDC 提供了怎样的替代方案

OIDC 的核心思路是让应用无需存储长期供应商密钥即可完成认证。一个受信任的签发方提供签名后的短期令牌来标识应用身份，接收服务在验证令牌后再决定授予什么权限。

这种机制有两个直接好处。被盗的令牌会在过期后失效，即使泄露未被发现，攻击窗口也被限制在令牌有效期内。同时，应用可以通过编程方式获取新凭证，不再需要在使用该凭证的各个系统之间分发和手动轮换持久密钥。

Vercel 已经在 Blob、AI Gateway 和 Sandbox 等服务中优先支持 OIDC。其 OIDC 联合身份功能自 2024 年起正式可用，允许运行在 Vercel 上的应用在配置了项目和环境的信任策略后，用 Vercel 签发的身份令牌换取 AWS、Google Cloud 和 Azure 的临时凭证。但要让开发者真正摆脱长期密钥，这种支持必须扩展到他们依赖的所有服务。

OIDC 建立在 OAuth 2.0 授权框架之上，其核心是引入一个标准化的身份层。在 OAuth 2.0 中，客户端获取的是访问令牌，但令牌本身不包含可验证的身份信息；OIDC 则通过 ID Token（一个签名的 JWT）来确认请求方的身份。令牌由受信任的签发方（Issuer）使用私钥签名，接收方通过签发方公开的 JWKS 端点获取公钥进行验签，无需与签发方实时通信。令牌中通常包含 iss（签发方）、sub（主体标识）、aud（受众）和 exp（过期时间）等声明，接收服务据此判断是否信任该令牌以及授予何种权限。这种基于非对称签名的验证模型，使得服务之间可以建立联邦信任，而无需共享任何长期密钥。

在机器对机器的场景中，OIDC 常与“工作负载身份”概念结合：运行在云平台或 CI/CD 环境中的工作负载，由平台作为签发方获得短期令牌，再向目标服务证明自己的身份。这与传统的 API 密钥模式形成鲜明对比——后者本质上是一个长期共享秘密，一旦泄露就等同于永久授权。OIDC 令牌的短有效期和受众限制，将泄露的影响范围限制在特定服务和时间窗口内。

现实困境：仅 8.4% 的 SaaS 供应商支持安全认证

Vercel 调查了超过 1000 家 SaaS 供应商，发现只有 8.4% 支持安全认证方法。这个数字揭示了行业现状：标准已经存在，但采用率极低。

更棘手的是，即使服务提供了安全方法，开发者往往仍选择静态密钥，因为用起来更简单。Vercel 总结出三个主要障碍：工具和设置让安全认证比使用静态密钥更复杂；在请求路径上获取或交换令牌会增加延迟；供应商缺乏提供和优先支持安全认证的动力。

这让人想起 HTTPS 普及前的状态——加密并非技术不可行，而是工具不够好用、激励不够明确。

Vercel 的三管齐下策略

面对这些障碍，Vercel 从三个方向同时推进。

降低使用门槛。 在 Vercel 上，代码通过函数调用获取 OIDC 令牌，并用自定义受众指定接收服务。Vercel Connect 让应用和代理在运行时用部署身份请求供应商令牌，无需在环境变量中存储长期密钥。连接器配置并关联到项目和用户账户后，代码即可请求该用户权限范围内的令牌。Vercel 还在将 OIDC 支持扩展到 API 和 CLI，以消除部署工作流中对长期 Vercel 令牌的依赖。

提供开箱即用的 UI 组件。 Vercel 推出了 OIDC UI，这是一个 shadcn/ui 组件注册表，包含信任策略配置器和服务器端令牌验证器。它内置了 Vercel、GitHub、GitLab、Google、Bitbucket、AWS、Azure 以及自定义 OIDC 签发方的表单。供应商可以让客户为特定 Vercel 项目的生产环境配置信任，然后根据该策略验证传入令牌，无需从零构建配置界面和验证代码。

减少性能开销。 静态密钥就在环境变量里，读取不需要网络请求。获取令牌或交换凭证可能增加网络延迟，因此减少这些调用是让安全认证变得实用的关键。Vercel Functions 在请求头中接收平台签发的令牌，SDK 直接读取而无需额外获取；平台会重用未过期的令牌，Vercel Connect 则在进程内缓存供应商令牌并在临近过期时刷新。自定义受众和供应商交换才需要网络调用。文中给出了用 Azure SDK 访问 Cosmos DB 的示例：通过 ClientAssertionCredential 将 Vercel OIDC 令牌交换为 Azure 访问令牌，从而避免使用数据库密钥。

给供应商的硬性时间表

HTTPS 的普及不仅靠易用性，更靠 Chrome 的“不安全”标签和截止日期。Vercel 正在复制这一策略。

到 2026 年 11 月 30 日，不支持从 Vercel 到其服务的 OIDC 认证、仍使用长期密钥进行认证的供应商，将在其 Marketplace 列表中看到类似的“不安全”提示。到 2027 年 1 月，不提供安全认证的供应商将被下架。Vercel 表示，其自有 API 和原生集成也将遵守同样的标准。

从静态到动态：Vercel 的一贯逻辑

Vercel 将这次转变描述为“从静态到动态”的延续——从静态页面到动态页面，现在轮到凭证。十五年前，加密每个请求看似多余；今天，挂锁图标已经平常到只有缺失时才会被注意。服务间的安全认证也应该变得同样寻常。

值得思考的是，Vercel 的强制措施能否真正推动行业跟进。8.4% 的采用率说明市场自发演进的速度太慢，而平台方的硬性截止日期可能比任何技术布道都更有效。当 Marketplace 的流量和曝光与认证方式挂钩时，供应商的动力问题将得到根本性改变。对于开发者而言，现在开始将应用迁移到 OIDC 流程，或许是在下一轮平台规则变化前最务实的准备。

背景补充

Vercel Connect 背后的关键技术是 OIDC 联合身份（OIDC Federation）。在传统云厂商的 IAM 体系中，联合身份允许外部身份提供方（如 Vercel）签发的令牌被信任，从而换取云平台自身的临时安全凭证。以 AWS 为例，需要配置 IAM Role 的信任策略，指定 Vercel 的 OIDC 签发方为可信主体，并限制 aud 和 sub 条件；应用运行时用 Vercel 令牌调用 AWS STS 的 AssumeRoleWithWebIdentity 接口，获得有效期通常为 15 分钟到 1 小时的临时凭证。Google Cloud 的 Workload Identity Federation 和 Azure 的 Federated Identity Credential 遵循类似逻辑。这种机制消除了在环境变量中长期存放云访问密钥的需要，也使得权限边界可以通过信任策略精确控制。

令牌缓存与刷新的设计需要在安全性和性能之间取得平衡。短期令牌的有效期通常只有几分钟到一小时，如果每次请求都重新获取或交换令牌，网络往返会显著增加延迟。常见做法是在进程内维护一个令牌缓存，记录令牌的过期时间，并在临近过期时（例如剩余有效期不足总时长的 20%）提前刷新，避免请求路径上出现“令牌已过期”的失败。刷新通常使用后台异步方式，不阻塞正在处理的请求。同时，缓存需要与令牌的受众和权限范围绑定，防止不同服务之间误用令牌。Vercel 在 Functions 中重用未过期令牌、在 Connect 中进程内缓存供应商令牌，正是这一模式的工程实现。