一文搞懂一天学会OIDC，别再停留在会用层面

      一天学会 OIDC：从“会用”到真正理解

OIDC 全称 OpenID Connect，是建立在 OAuth 2.0 之上的身份认证协议。它解决了一个很关键的问题：OAuth 2.0 只能回答“这个应用有没有访问权限”，OIDC 则能回答“当前用户到底是谁”。

所以一句话记住：OAuth 2.0 管授权，OIDC 管认证;OIDC 是在 OAuth 2.0 上增加了一个身份层。

1. 先分清三个角色

OIDC 里有三个核心角色：

用户：真正要登录的人。

OpenID Provider / IdP：身份提供方，负责验证用户身份并发放令牌，例如 Google、Microsoft Entra ID、Authing、Keycloak 等。

Relying Party / Client：依赖方，也就是你的应用。它自己不管理密码，而是通过 IdP 确认用户身份。

2. 最关键的三个令牌

OIDC 里最容易混淆的就是 Token，必须分清：

ID Token：证明“用户是谁”。它是 JWT 格式，必须签名，包含 iss、sub、aud、exp 等声明。

Access Token：证明“应用能访问哪些资源”。它主要用于调用 API，不应用作身份凭证。

Refresh Token：用于在 Access Token 过期后换取新的 Access Token。

重点：ID Token 才是 OIDC 的核心产物。没有 ID Token，就只是 OAuth 2.0 授权流程;有了 ID Token，才构成 OIDC 认证流程。

3. ID Token 里最重要的字段

ID Token 是 JWT，结构为 Header.Payload.Signature。

校验时必须关注这些声明：

iss：签发者，必须与可信 IdP 的地址一致。

sub：用户在该 IdP 下的唯一标识，判断“是不是同一个用户”应看 (iss, sub) 组合。

aud：受众，通常应等于你的 client_id。

exp：过期时间，过期后必须拒绝。

iat：签发时间。

nonce：防重放，必须与请求时发送的值一致。

auth_time：认证发生时间，配合 max_age 判断是否需要重新登录。

4. 授权码流程怎么走

现在最推荐的是 Authorization Code + PKCE 流程。

流程如下：

用户访问你的应用。

应用把用户重定向到 IdP 登录页，带上 client_id、redirect_uri、scope=openid、state、code_challenge 等参数。

用户在 IdP 完成登录并授权。

IdP 返回一个授权码 code。

应用在后端用 code、client_id、code_verifier 等去换取 ID Token 和 Access Token。

应用验证 ID Token。

验证通过后，建立本地会话，允许用户访问受保护资源。

注意：浏览器应用、移动应用、SPA 都不建议再使用 Implicit Flow，应优先使用 Authorization Code + PKCE。

5. ID Token 校验清单

收到 ID Token 后不能直接解码使用，必须校验。完整校验顺序建议这样：

检查算法白名单：只接受预期算法，如 RS256，拒绝 alg: none。

根据 kid 取公钥：从 IdP 的 JWKS 端点获取公钥，并做缓存和刷新。

验证签名：确认 Token 确实由该 IdP 签发。

校验 iss：必须精确匹配可信 IdP。

校验 aud：必须包含当前应用的 client_id。

校验 exp：不能过期。

校验 iat：签发时间应合理。

校验 nonce：如果请求中带了 nonce，返回的 ID Token 必须一致。

必要时校验 auth_time：用于强制近期重新认证。

只要其中任何一项失败，都应视为认证失败。

6. 常见安全要点

state 参数必须有：用于防 CSRF。

redirect_uri 必须精确匹配：防止被劫持到恶意地址。

不要把 Access Token 当成身份证明：它只代表访问权限。

不要接受 alg: none：这是经典 JWT 伪造漏洞。

公钥不要硬编码：应通过 JWKS 动态获取并缓存。

Token 不要存在不安全位置：浏览器端尤其要避免随意暴露在 localStorage 中