AI Agent 身份认证实战：从 OAuth 到 OIDC

核心思路：让 Agent 拥有独立身份

AI Agent 在自主执行任务时，本质上是一个需要访问受保护资源的客户端。传统的人机交互中，我们用 OAuth 2.0 授权用户，但给 Agent 做身份认证时，直接套用旧范式会遇到问题：Agent 没有浏览器、无法完成交互式登录，且会话生命周期需要程序化控制。我倾向于用 OpenID Connect (OIDC) 的 Authorization Code Flow with PKCE 方案，通过服务端代理或预授权机制，让 Agent 获得独立的 Access Token 和 ID Token。

为什么 PKCE 是 Agent 的正确选择

传统的 OAuth 2.0 授权码流程依赖 Client Secret 来保护重定向后的令牌交换，但在无浏览器的自动化场景中，存储和管理 Secret 增加了攻击面。PKCE（Proof Key for Code Exchange）通过代码验证器（code_verifier）和代码挑战（code_challenge）的哈希映射，在不依赖 Secret 的情况下防止授权码被拦截重放。

对于 AI Agent 来说，这意味着我们可以采用“设备授权”或“预置凭证 + PKCE 刷新”的模式。Agent 持有初始的 Refresh Token，后续通过后台静默刷新 Access Token，而无需每次人工介入登录。

落地步骤：配置 OIDC 客户端

在 Identity Provider (IdP) 端，我需要创建一个专门的 Client 配置给 Agent 使用：

1. Grant Types: 仅启用 authorization_code 和 refresh_token。禁用 implicit，因为 Agent 不应处理碎片标识符。
2. PKCE: 强制开启 S256 代码挑战方法。这是安全性的基石。
3. Scopes: 最小权限原则。只开放 Agent 所需的 Scope，如 openid profile offline_access，避免授予 admin 或 user.readwrite.all 等过大权限。
4. Redirect URIs: 如果 Agent 是完全无头（headless）的，可以配置一个专用的内部回调地址，或者使用 localhost 配合本地服务器捕获回调，但这通常只适合调试。生产环境更推荐 urn:ietf:wg:oauth:2.0:oob 这种带外方式，或者由管理后台完成一次性授权后，将 Refresh Token 注入 Agent 配置。

代码实现：Agent 发起授权

在 Node.js 环境中，我使用 crypto 模块生成 PKCE 参数，这是任何标准 OAuth 库底层的通用逻辑：

const crypto = require('crypto');

// 生成 code_verifier
const codeVerifier = crypto.randomBytes(32).toString('base64url');
// 生成 code_challenge (S256)
const codeChallenge = crypto
  .createHash('sha256')
  .update(codeVerifier)
  .digest('base64url');

const authUrl = `${ISSUER_URL}/authorize?`
  + `client_id=${CLIENT_ID}`
  + `&redirect_uri=${REDIRECT_URI}`
  + `&response_type=code`  
  + `&scope=openid profile offline_access`  
  + `&code_challenge=${codeChallenge}`  
  + `&code_challenge_method=S256`;

Agent 执行到这一步时，通常需要触发一次人工授权（或在配置阶段由管理员完成）。拿到 Code 后，后续 Token 交换由 Agent 在服务端完成，并将 Refresh Token 加密存储。

常见陷阱：Token 生命周期管理

我在实践中发现，最容易出问题的地方是 Token 刷新逻辑。Agent 往往长时间运行，Access Token 过期后如果刷新失败，任务会立即中断。建议实现指数退避重试，并监控 invalid_grant 错误——这通常意味着 Refresh Token 已失效，需要重新触发完整的授权流程。

此外，不要将 Agent 的身份伪装成人类用户去访问 API，这会破坏审计追踪。IdP 应支持 grant_type=client_credentials 或专门的 device_code 流，以便在日志中明确区分“Agent 行为”和“人工行为”。

下一步实践

如果你们正在构建多 Agent 协作系统，可以考虑引入 JWT 形式的 Agent 身份描述，而不仅仅是标准的 OIDC ID Token，以实现更细粒度的权限控制。