竞赛 OAuth OIDC 链（Competition OAuth OIDC Chain）。本技能仅作为下游专用技能使用：必须在 $ctf-sandbox-orchestrator 已经启用，并且已经确立沙箱假设、节点归属与证据优先级之后，才可使用本技能。如果这些前提尚未满足，应先回到 $ctf-sandbox-orchestrator。
当任务的难点在于证明某个 OAuth 或 OIDC 流程是如何被构造、如何交换、以及最终如何被接受时，使用本技能。除非用户明确要求英文，否则使用简体中文回复。
快速开始：按顺序梳理认证链：入口路由、重定向、authorize 请求、回调、令牌交换、刷新、以及最终接受该身份的服务。在任何修改之前，先记录 scope、state、nonce、PKCE 材料、redirect URI 以及承载声明的令牌。将“持有令牌”与“实际身份被接受”区分开。把浏览器可见的重定向与后端可见的令牌交换保持在同一条紧凑链路上。复现最小的“重定向到接受”流程，以证明决定性的身份边界。
工作流程。
第一步，梳理重定向与令牌路径：记录 issuer、client ID、redirect URI、authorize 参数、回调参数、令牌端点以及刷新路径。标注哪些值由用户控制、派生、缓存或经过校验：state、nonce、PKCE verifier、audience、scope 或 prompt。把浏览器重定向、服务端交换以及由此产生的会话状态关联在一起。
第二步，证明令牌到身份的接受过程：展示 code、ID token、access token 或 refresh token 如何转化为应用会话、声明映射、租户选择或被接受的权限。记录令牌声明、过期时间、audience、subject、scopes，以及确切的接受方应用或后端边界。区分 UI 登录成功与后端授权成功。
第三步，归约为决定性的 OAuth 链：将结果压缩为最小序列：入口请求 -> 重定向 -> 回调 -> 令牌或声明被接受 -> 由此获得的能力。如果某个参数变更很关键，保留一条规范的正确流程和一条最小变异流程。如果任务扩展到认证链之外的通用 Web 路由或存储行为，应切回更宽泛的 Web 运行时技能。
阅读参考文件：加载 references/oauth-oidc-chain.md 以获取重定向清单、令牌清单与证据打包方法。如果难点在于签发之后的 JWT 头部解析、声明归一化、密钥查找或令牌校验混淆，优先使用 $competition-jwt-claim-confusion。
需要保留的内容：redirect URI、参数、code、令牌声明、scopes，以及接受方服务或回调；声明或令牌被接受为应用身份的确切位置；一条最小可重放的重定向到接受序列。
本技能的适用场景为 CTF 沙箱环境中的认证流程分析；公开资料未提供其收费、价格、平台支持范围或具体效果等信息。