3. OIDC 协议基础：核心概念与授权流程
OpenID Connect (OIDC) 是构建在 OAuth 2.0 之上的身份认证层。它通过引入标准化的 ID Token、UserInfo 端点以及明确的流程定义，使客户端能够安全地验证用户身份并获取基本用户信息。本节将深入剖析 OIDC 的核心概念，并对比两种最常用的授权流程。
3.1 OIDC 核心概念
OIDC 协议围绕三个核心组件构建，它们共同构成了身份认证与授权的数据基础。
| 核心概念 | 载体/格式 | 核心用途 | 关键特征 |
|---|---|---|---|
| ID Token | JWT (JSON Web Token) | 用户身份认证 | 包含用户标识 (sub)、签发者 (iss)、受众 (aud)、过期时间 (exp) 等声明；由授权服务器签名，客户端可验证其完整性。 |
| Access Token | 不透明字符串 或 JWT | 授权访问资源 | 用于访问受保护的 API 或资源服务器；客户端无需解析其内部结构，仅作为凭证传递。 |
| UserInfo 端点 | REST API (返回 JSON) | 获取用户详细信息 | 客户端使用 Access Token 调用此端点，获取标准化的用户声明（如姓名、邮箱、头像等）。 |
架构提示： 在 Redis 缓存集成方案中，ID Token 通常不缓存，因其仅在登录时验证一次；Access Token 可缓存至其过期时间，以减少对授权服务器的验证请求；UserInfo 端点的响应结果可缓存，以加速用户信息查询，但需注意缓存失效策略。
3.2 授权码流程 (Authorization Code Flow)
授权码流程是 OIDC 中最安全、最常用的流程，特别适用于有后端服务的 Web 应用。它通过一个临时的“授权码”来交换令牌，确保敏感凭证（如客户端密钥）不会暴露给用户代理（浏览器）。
- 用户发起登录： 客户端（Web 应用）将用户重定向到 OIDC 授权服务器的认证端点。
- 用户认证并授权： 用户在授权服务器上登录，并同意客户端请求的权限。
- 返回授权码： 授权服务器通过浏览器重定向，将授权码发送回客户端的回调端点。
- 交换令牌： 客户端后端使用授权码、客户端 ID 和客户端密钥，直接与授权服务器的令牌端点通信，换取 ID Token 和 Access Token。
- 获取用户信息（可选）： 客户端使用 Access Token 调用 UserInfo 端点，获取用户详细信息。
3.3 隐式流程 (Implicit Flow)
隐式流程是为纯前端应用（如单页应用 SPA）设计的简化流程。它直接返回 Access Token，跳过了授权码交换步骤。由于安全性较低（令牌直接暴露在浏览器 URL 中），OAuth 2.0 安全最佳实践已不推荐使用，建议使用授权码流程 + PKCE 替代。
- 用户发起登录： 客户端将用户重定向到授权服务器的认证端点。
- 用户认证并授权： 用户在授权服务器上登录并授权。
- 直接返回令牌： 授权服务器通过浏览器重定向，直接在 URL 片段 (#) 中返回 Access Token 和 ID Token。
- 获取用户信息（可选）： 客户端使用 Access Token 调用 UserInfo 端点。
安全警告： 隐式流程不返回 Refresh Token，且 Access Token 可能被浏览器历史记录或 Referer 头泄露。在架构调优中，若必须支持纯前端应用，应优先采用授权码流程 + PKCE (Proof Key for Code Exchange) 方案，以兼顾安全性与用户体验。
3.4 流程对比与选型建议
| 对比维度 | 授权码流程 | 隐式流程 |
|---|---|---|
| 安全性 | 高（令牌在后端交换） | 低（令牌暴露在浏览器） |
| 适用客户端 | 有后端服务的 Web 应用、移动应用 | 纯前端应用 (SPA) — 已不推荐 |
| 是否支持 Refresh Token | 是 | 否 |
| 令牌交换步骤 | 需要（授权码 → 令牌） | 不需要（直接返回令牌） |
| Redis 缓存策略 | 可缓存 Access Token 和 UserInfo 响应 | 可缓存 UserInfo 响应，但 Access Token 生命周期短 |
架构决策： 在《Redis 缓存与 OIDC 集成部署》方案中，我们默认采用授权码流程。Redis 将用于缓存 Access Token 的验证结果（减少对授权服务器的内网调用）以及 UserInfo 端点的响应（加速用户信息查询）。对于纯前端应用，我们通过引入 PKCE 扩展来增强授权码流程的安全性，而非回退到隐式流程。