WorkOS 本周发布了 auth.md——一个开放规范加上一个具体的文件 artifact,解决几乎每个 agent 团队都在手工拼装的问题:agent 如何证明它正在代表用户 X 行动,凭证是 user-scoped、可吊销的、而不是塞在环境变量里的裸 API key。形状:一个小的 Markdown 文件由应用程序发布在服务根目录(既作为人类开发者的文档,也作为 agent 能在运行时以编程方式读取的 artifact),加上 OAuth 2.0 元数据扩展。对那些把 agent 部署到生产环境、需要代表用户调用第三方 API 的 builder 来说,这是处理正确问题的规范。
发现是一个两跳元数据链。Agent 打 `/.well-known/oauth-protected-resource`(Protected Resource Metadata)以找到 authorization server,然后获取 `/.well-known/oauth-authorization-server`,其中包含一个新的 `agent_auth` 块,有四个 URI:`register_uri`、`claim_uri`、`revocation_uri` 和 `identity_types_supported`。新 grant 类型是 ID-JAG(Identity-scoped JSON Authorization Grant)按 RFC 9728——agent 身份提供者通过签名 JWT 来证明用户身份,authorization server 验证这个断言,返回 scoped 凭证。受保护端点上的 401 响应包含 `WWW-Authenticate: Bearer resource_metadata="..."`,使 agent 无需预先配置即可启动到发现链中。OpenAI、Anthropic 和 Cursor 被引用为潜在的身份提供者;规范不要求任何单一供应商。
与 RFC 7591 动态客户端注册的区别很重要,规范对此说得很明确。RFC 7591 让一个客户端向 authorization server 注册自己——有用,但客户端以*它自己*的身份认证。auth.md 解决一个不同的问题:agent 以*用户*的身份认证,代表用户,authorization server 理解这个区别并发放 user-scoped 可吊销的凭证。这是 agent-loop 世界的正确原语:一个调用 `send_email` 的 agent 应该以用户的 email 权限行动,而不是以全局的「我是 agent 服务」权限行动,用户应该能够撤销这个特定 agent 的访问而不必轮换自己的凭证。今天大多数 agent 产品要么让用户粘贴裸 API key(不安全、每个 agent 不可吊销),要么通过 agent 厂商自己的 auth 运行一切(锁定)。auth.md 是标准化的中间道路。
周一上午:如果你在 ship 一个需要代表用户调用第三方 API 的 agent,阅读 github.com/workos/auth.md 上的规范,检查你的 auth 提供者(Auth0、Okta、自定义)是否有走向 ID-JAG 支持的路线图。诚实的缺口是实现状态——只有 early access,没有广泛的生产服务器,文章指出 MCP server 或裸 LLM API 调用在此阶段通常不能参与 agent-verified 流程。与现有 OAuth 库的兼容性在发布中没有明确处理;预期会有 rough edges。但架构决定是合理的:这是 AWS MCP 服务器的 IAM-OAuth 桥在资源端解决的同一问题的用户端,agent 基础设施栈两边都需要。WorkOS 在规范上很早;问题是 OpenAI、Anthropic 和云厂商是几个月还是几个季度 ship 互操作。