OpenID Connect

构建在 OAuth 2.0 之上的认证层:用 ID Token(JWT)传递认证结果,标准化发现文档与用户信息端点;适合单点登录与第三方登录场景。

OpenID Connect 是什么

OpenID Connect 是构建在 OAuth 2.0 之上的认证层,用 ID Token(一个 JWT)传递认证结果,并标准化了发现文档与用户信息端点。授权服务器在授权码流程中额外返回 ID Token,客户端据此确认用户身份,而不必自己拼装认证流程。

与 OAuth 2.0 的关系

OAuth 2.0 给客户端一张能代表用户访问资源的通行证,但没有回答用户是谁;OIDC 补上这一块。因此做单点登录应选择 OIDC,做第三方数据访问授权应选择 OAuth 2.0,两者经常组合出现:一次授权既拿到访问令牌也拿到身份令牌。

基本信息

产物ID Token 与 Access Token,ID Token 描述认证事件
发现机制约定路径下的配置文档提供端点与算法元数据
校验要点签名、签发方、受众、随机数与过期时间
用户信息通过用户信息端点获取,避免把全部声明塞进令牌

客户端校验清单

客户端校验清单
1. 读取发现文档,确认端点地址与支持的签名算法
2. 校验 ID Token 签名(使用提供方公钥,优先从发现文档获取)
3. 校验签发方与受众是否匹配本客户端
4. 校验随机数与会话绑定,防止令牌重放
5. 校验过期与签发时间,容忍合理的时钟偏差
# 任何一步失败都应终止登录,不要降级放行

典型使用场景

  • 单点登录:一次登录访问多个内部系统
  • 第三方登录:用外部身份提供方完成注册与登录
  • 移动端与桌面应用登录:结合授权码与 PKCE
  • 服务间可信身份传递:以内网令牌换取服务身份
  • 跨系统用户信息同步:通过标准端点获取标准声明

常见部署形态

自建场景下通常用一套授权服务器统一承担登录与令牌签发,各业务系统只作为客户端接入;使用外部身份提供方时,客户端仍需在本地校验令牌,不能只依赖前端拿到的登录状态。前后端分离的架构里,后端必须独立校验令牌,前端存储的登录标记不能作为授权依据。

访问令牌不等于身份:业务鉴权应基于授权范围与资源本身判断,而不是把令牌当作可信的用户档案使用。

易错点

  • 只校验签名不校验受众与签发方,令牌可被搬到其他应用使用
  • 把 ID Token 当作调用后端接口的凭证,混淆认证与授权
  • 不校验随机数与状态参数,登录流程可被重放或劫持
  • 忽略时钟偏差,令牌刚签发就被判定为无效,登录随机失败

数据来源与参考

  • OpenID Connect Core 1.0 规范
  • RFC 8414:Authorization Server Metadata
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌