WorkOS 发布 auth.md：基于 OAuth 标准的 AI 代理开放注册协议

一句话看懂

WorkOS 发布 auth.md 协议，让 AI 代理通过标准化的 Markdown 文件自动发现并完成注册，无需人工干预。

详细发生了什么

WorkOS 推出了 auth.md，一个基于 OAuth 标准的开放代理注册协议。传统上，AI 代理要接入一个服务，需要人类手动填写表单、复制 API key，这既低效又难以审计。auth.md 通过在服务域名下发布一个 Markdown 文件（如 https://service.com/auth.md ），告诉代理如何注册：支持哪些流程、有哪些 scope、如何获取凭证。

发现机制分两步：首先，API 返回 401 时附带 WWW-Authenticate 头指向 Protected Resource Metadata（PRM）；然后代理获取 PRM 和 Authorization Server 元数据，读取 agent_auth 块中的 register_uri、claim_uri、revocation_uri 等端点。

auth.md 定义了两种注册流程：

代理验证流程：代理的身份提供商（如 OpenAI、Anthropic）在注册时证明用户身份，代理获取 ID-JAG 令牌并 POST 到应用端点，应用验证签名后同步返回凭证。无需 OTP 或邮件。
用户认领流程：基于 OTP，无需代理提供商参与。代理先注册（可匿名或提供邮箱），然后用户通过邮件中的一次性代码绑定注册，升级权限。

凭证可以是 access_token 或 api_key，通过 Authorization: Bearer 头发送。审计事件包括 registration.created、claim.confirmed 等，便于追踪。

中文圈视角

auth.md 对中文开发者意味着什么？

国内能用吗？ 协议本身是开放的，不依赖 WorkOS 账户，任何服务都可以实现。但 ID-JAG 流程依赖 OpenAI、Anthropic 等国外平台，国内代理（如 DeepSeek、Kimi）尚未支持类似身份断言机制。用户认领流程（OTP）则完全可行，适合国内场景。
国产平替？ 目前国内没有直接对标 auth.md 的开放协议。类似需求通常通过自定义 API key 管理或 OAuth 2.0 设备授权流程解决。ModelScope 或百度千帆等平台可参考此协议，为国内代理提供标准化注册接口。
监管与合规：代理注册涉及用户身份绑定和权限委托，国内数据安全法要求用户授权明确。用户认领流程的 OTP 验证符合实名制要求，而代理验证流程需确保身份提供商合规。
中文场景价值：对于国内 SaaS 服务（如飞书、钉钉），auth.md 可让 AI 助手自动注册并获取权限，减少人工配置。但需注意，国内代理生态尚不成熟，协议推广需平台方支持。

几条值得记住的细节

auth.md 文件是纯文本 Markdown，同时作为人类文档和机器可读的运行时 artifact。
代理验证流程的 access_token 不含 refresh token，代理必须用新 ID-JAG 延长访问。
用户认领流程有两种起始形态：匿名启动（先发凭证后绑定）和邮箱必需（先验证后发凭证）。
用户匹配顺序：先按 (iss, sub) 匹配已有委托记录，再匹配已验证邮箱，最后 JIT 创建新用户。
审计事件包括 registration.expired 和 registration.revoked，便于安全运维。

一句话总结

auth.md 让 AI 代理像人类一样“注册”应用，简化了自动化工作流的授权门槛。