GitHub Actions OIDC 令牌验证器

要解决什么问题

在云上部署工作流里，CI 产出的凭证是最常见的攻击面之一。GITHUB_TOKEN 权限宽、生命周期长，一旦泄露就能读写仓库甚至触发供应链操作。GitHub Actions 提供的 OIDC 方案把短期身份令牌直接发给云厂商，但拿到的令牌本身并不会被自动信任——你仍然需要在云端验证三件事：是谁签发的（issuer 与 JWKS 公钥）、为谁签发的（subject 声明）、允许给哪个 audience 用。少了任何一环，攻击者都可能拿一个伪造或过期的令牌换取云凭证。这个技能把这几步打包成一个可复用的验证逻辑，省掉每次手写 JWT 解析和密钥拉取的重复劳动。

核心能力与工作步骤

技能围绕 GitHub OIDC 提供商的 JWKS 端点展开，主要做四件事：

• 签名验证：从 https://token.actions.githubusercontent.com 的 JWKS 端点拉取公钥集，用对应的密钥校验 JWT 签名，确认令牌确实由 GitHub 签发，而非本地伪造。
• Issuer 与 audience 校验：比对令牌的 iss 声明是否等于 GitHub OIDC 提供商地址，aud 是否落在你指定的范围（例如某个 Azure 资源 ID）内，防止令牌被重放到其他服务。
• Subject 声明检查：解析 sub 字段，确认它符合 repo:<org>/<repo>:type:<branch-or-ref> 这类格式，从而锁定这个令牌来自哪个仓库的哪条流水线。
• 仓库归属与部署上下文绑定：结合 repository ownership 信息，确认发起部署的仓库属于预期组织，而不是同名的第三方仓库或 fork。

整体流程大致是：接收上游传来的 OIDC 令牌 → 拉取并缓存 JWKS → 验签 → 逐条校验 iss、aud、sub 与仓库归属 → 返回验证结论。因为每一步都是确定性的校验而非生成逻辑，它更适合嵌入到部署前置检查或自定义信任网关里，而不是当作一个独立的部署工具来跑。

适用边界与注意点

• 只解决验证环节：技能不会帮你生成令牌、申请云凭证或完成 IAM 角色绑定，这些仍需按云厂商的 OIDC 联机流程配置。
• 依赖网络可达 JWKS 端点：如果运行环境无法访问 token.actions.githubusercontent.com，签名验证就无法进行，缓存策略需要你自己在部署侧考虑。
• Key rotation 需要跟进：GitHub 侧轮换签名密钥后，本地缓存的公钥集可能短暂不匹配，需要设计合理的刷新间隔，避免新令牌被误判为无效。
• 不能替代权限最小化：即使令牌验证通过，依然要在 Actions workflow 里限制 GITHUB_TOKEN 的 permissions，否则验证只是一个入口门槛，不是纵深防御的全部。
• 适合部署前检查，不是运行时组件：把它放在流水线的验证步骤或云侧的信任代理里更自然，直接塞进业务代码路径反而会增加不必要的耦合。