Rubygems.org 中 Buildkite OIDC 令牌的 JTI 声明问题解析

在 Rubygems.org 项目的 API 密钥角色功能集成过程中，开发团队发现了一个与 Buildkite OIDC 令牌相关的重要兼容性问题。这个问题涉及到现代身份验证协议中的一个关键安全特性——JTI（JWT ID）声明。

问题背景

OIDC（OpenID Connect）是基于 OAuth 2.0 协议的身份验证层，它使用 JWT（JSON Web Token）作为令牌格式。JWT 中包含多个标准声明（claims），其中 JTI 是一个重要的安全声明，用于防止令牌重放攻击。

Rubygems.org 在实现 API 密钥角色功能时，系统要求所有 OIDC 令牌必须包含 JTI 声明。然而，当时 Buildkite 生成的 OIDC 令牌并未包含这一关键声明，导致集成失败。

技术细节分析

Buildkite 是一个流行的持续集成和交付平台。当它作为身份提供者（IdP）时，会颁发包含以下典型声明的 OIDC 令牌：

• iss（签发者）：标识令牌的签发机构
• sub（主题）：标识令牌的主体
• aud（受众）：指定令牌的目标接收方
• 标准时间声明（iat、nbf、exp）：定义令牌的生命周期
• 平台特定声明：如组织、流水线、构建信息等

在最初的问题版本中，这些令牌缺少了 JTI 声明，这是一个用于唯一标识 JWT 的声明，对于防止令牌重放攻击至关重要。

解决方案与改进

Buildkite 团队迅速响应，在其 OIDC 令牌实现中添加了 JTI 声明。以下是改进后令牌的典型结构示例（部分字段已脱敏）：

{
  "iss": "https://agent.buildkite.com",
  "sub": "organization:example-org:pipeline:example-pipeline...",
  "aud": "rubygems.org",
  "iat": 1736757460,
  "nbf": 1736757460,
  "exp": 1736757760,
  "jti": "0194b014-8517-7cef-b232-76a827315f08",
  "organization_slug": "example-org",
  "pipeline_slug": "example-pipeline",
  "build_number": 5,
  "build_branch": "main",
  "build_commit": "b5ffe3aeea51cec6c41aef16e45ee6bce47d8810",
  "job_id": "01945ecf-80f0-41e8-9b83-a2970a9305a1",
  "agent_id": "01945ecf-8bcf-40a6-9d70-a765db9a0928"
}

安全意义

JTI 声明的加入显著提升了系统的安全性：

1. 防重放攻击：每个令牌都有唯一标识符，服务端可以记录已使用的 JTI 来防止令牌被重复使用
2. 审计追踪：为安全事件调查提供了更好的追踪能力
3. 符合标准：使实现更符合 JWT 和 OIDC 规范要求

实施建议

对于需要在 CI/CD 流程中使用 OIDC 令牌的开发团队，建议：

1. 验证令牌中是否包含必要的安全声明（如 JTI）
2. 实现令牌验证时检查 JTI 的唯一性
3. 考虑设置适当的令牌有效期（如示例中的 5 分钟）
4. 根据实际需求限制令牌的权限范围

这个案例展示了现代身份验证协议实现中细节的重要性，也体现了开源社区通过协作快速解决问题的优势。