1. OIDC 协议基础
OIDC（OpenID Connect）是构建在 OAuth 2.0 之上的身份认证层协议。理解 OIDC 与 OAuth 2.0 的关系、令牌类型以及核心角色，是优化授权码流程异步编排的前提。
1.1 OIDC 与 OAuth 2.0 的关系
OAuth 2.0 本质是授权框架，解决“谁可以访问什么资源”的问题；OIDC 在此基础上增加身份认证层，解决“用户是谁”的问题。两者是“扩展”而非“替代”关系。
| 维度 | OAuth 2.0 | OIDC |
|---|---|---|
| 核心目标 | 授权（Access Token） | 认证（ID Token） |
| 令牌类型 | Access Token、Refresh Token | ID Token + Access Token + Refresh Token |
| 用户身份 | 不关心用户身份 | 通过 ID Token 携带用户身份声明 |
| 标准规范 | RFC 6749 | OIDC Core 1.0 |
| 典型场景 | API 授权、第三方登录授权 | 单点登录（SSO）、用户信息获取 |
关键理解：OIDC 不是重写 OAuth 2.0，而是在授权码流程的令牌响应中额外返回一个 JWT 格式的 ID Token，用于客户端验证用户身份。
1.2 ID Token 与 Access Token 的区别
两种令牌在异步任务编排中承担不同职责，混淆使用会导致安全漏洞或架构设计错误。
| 属性 | ID Token | Access Token |
|---|---|---|
| 格式 | JWT（必须） | JWT 或 opaque（不透明） |
| 用途 | 客户端验证用户身份 | 授权访问受保护资源 |
| 受众（aud） | 客户端 ID（client_id） | 资源服务器（API） |
| 生命周期 | 短（通常几分钟到几小时） | 可长可短（取决于资源服务器策略） |
| 是否可撤销 | 通常不撤销（无状态验证） | 可撤销（黑名单或自省端点） |
| 包含声明 | sub、name、email、iss、aud、exp、iat 等 | scope、client_id、授权范围等 |
常见误区：不要将 ID Token 作为 API 调用的凭证发送给资源服务器。ID Token 仅用于客户端本地验证用户身份，资源服务器应只信任 Access Token。
1.3 授权码流程的核心角色
OIDC 授权码流程涉及四个核心角色，每个角色在异步任务编排中承担不同的并发与安全职责。
- 终端用户（End User）：资源所有者，通过浏览器发起认证请求。
- 客户端（Client）：需要验证用户身份的应用程序（如 Web 前端、移动 App、后端服务）。
- 授权服务器（Authorization Server）：负责用户认证、发放授权码和令牌（如 Keycloak、Auth0、自建 OIDC 服务）。
- 资源服务器（Resource Server）：托管受保护 API，验证 Access Token 后返回用户资源或数据。
异步编排视角：步骤⑥（授权码→令牌交换）是典型的 I/O 密集型操作，适合使用异步任务编排（如 CompletableFuture、协程）来避免阻塞客户端线程。步骤⑧（资源请求）可进一步拆分为多个并行子任务，提升整体吞吐量。
1.4 角色在异步场景下的职责边界
| 角色 | 同步场景职责 | 异步编排优化点 |
|---|---|---|
| 终端用户 | 等待认证完成 | 无（用户交互不可异步化） |
| 客户端 | 阻塞等待令牌响应 | 使用非阻塞 HTTP 客户端 + 异步回调 |
| 授权服务器 | 同步处理令牌请求 | 支持并发令牌请求，避免数据库锁竞争 |
| 资源服务器 | 同步验证令牌 | 缓存公钥（JWKS）减少远程调用 |