OIDC认证授权协议核心 | Java|Spring Security|Spring Boot|Spring Cloud|https://felord.cn 码农小胖哥的博客

OIDC是在OAuth2的基础上做了一个身份认证层，以便于客户端知晓授权的终端用户（End User），在客户端获取access_token的同时一并提供了一个用户的身份认证信息Id Token，它必须使用JWT格式。

OIDC几个关键术语

EU End User的缩写，指的是一个最终用户。
RP Relying Party的缩写，指的是OAuth2中的受信客户端，身份认证和授权信息的消费方。
OP OpenID Provider的缩写，指的是有能力提供EU认证的服务（比如OAuth2中的授权服务），用来为RP提供EU的身份认证信息。

其它还有一些术语，参见OIDC术语列表。

OIDC协议簇

OIDC包含了很多规范，最小的规范是 OIDC Core，下图是一个比较老的图，已经有点过时了，不过在一定程度上也能帮助你理解OIDC。

OpenID Connect Spec Map

Core OIDC核心，定义了OIDC的核心流程，如何在 OAuth 2.0 之上的身份验证以及使用声明来传达有关最终用户（EU）的信息。
Discovery 定义客户端如何动态发现有关 OpenID 提供者(OP)的信息。
Dynamic Registration 定义客户端如何动态注册到 OpenID 提供者。
OAuth 2.0 Multiple Response Types 定义了几个特定的新 OAuth 2.0 响应类型。
OAuth 2.0 Form Post Response Mode 定义如何通过User Agent使用 HTTP POST 自动提交的 HTML 表单值返回 OAuth 2.0 授权响应参数（包括 OpenID Connect 身份验证响应参数）。
RP-Initiated Logout 定义RP如何向OP请求退出一个EU。
Session Management 会话管理，用于规范OIDC服务如何管理Session信息。
Front-Channel Logout 基于前端的注销机制，使得RP可以不使用OP的iframe来退出。
Back-Channel Logout 基于后端的注销机制，定义了RP和OP之间如何通过交互来完成注销。
OpenID Connect Federation 联合认证，定义 OP 和 RP 集如何通过使用联合操作符建立信任。
Initiating User Registration via OpenID Connect 定义 prompt=create 身份验证请求参数。

两个基于Web的RP实施指南

Basic Client Implementer’s Guide 使用OAuth2授权码流来实现基于Web的RP的核心功能的简单子集
Implicit Client Implementer’s Guide 使用OAuth2隐匿流来实现基于Web的RP的核心功能的简单子集

迁移规范

OpenID 2.0 to OpenID Connect Migration 1.0 OpenID Authentication 2.0 是一种流行的身份验证联合协议， OpenID Connect 是 OpenID Authentication 的新版本，该规范定义了如何迁移到新的OpenID Connect。

还有一些草案正在孵化中，这里就不多介绍了。

OIDC核心流程

OIDC 被抽象为以下5个步骤，如图：

在这里插入图片描述

① RP（客户端）向 OpenID 提供者（OP）发送请求。
② OP 对最终用户进行身份验证并获得授权。
③ OP 使用 ID 令牌响应，通常是访问令牌。
④ RP 可以向 UserInfo 端点发送带有访问令牌的请求。
⑤ UserInfo 端点返回有关最终用户的claims。

对比OAuth2，RP就是OAuth2客户端，这个时候发送的请求不是授权请求了，而是认证（AuthN）请求；OP也就是OAuth2授权服务器，它需要在OAuth2的基础上提供EU(资源所有者)的claims以及身份认证令牌Id Token。

OIDC认证授权流程中必须包含授权范围openid。

Id Token

Id Token是OIDC的特有概念，它是一个包含用户信息（claims）的JWT令牌，如下所示：

eyJ4NXQjUzI1NiI6IlN4cXFkV1l4VDdCWnJkSC11VnBnQUhmWDJxMzRxUHl4eDRvblg2bXYtcUkiLCJraWQiOiJqb3NlIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJ1c2VyIiwiYXVkIjoiZTJmYTdlNjQtMjQ5Yi00NmYwLWFlMWQtNzk3NjEwZTg4NjE1IiwiYXpwIjoiZTJmYTdlNjQtMjQ5Yi00NmYwLWFlMWQtNzk3NjEwZTg4NjE1IiwiaXNzIjoiaHR0cDpcL1wvbG9jYWxob3N0OjkwMDAiLCJleHAiOjE2NTM2MjUxMjgsImlhdCI6MTY1MzYyMzMyOCwibm9uY2UiOiJXNm5LeTlxZnFWMkRvSDN1TDVGVGNVOUVGR2k4dWlqay1lcDIyV3RGQ2NZIn0.VDBOF867LnQIB52XGkSMT6hAu0NpyJsPA3soIAt3WWb4dwDmdiMrq5xpRuewURknmBmhZaJHT2QETEFWGhwB5gnq4kw4yPlvOpUuKxqfPsr9plA0HV_mQF9WFearRmVI12hGBrgj0Htgf4I5K6Nz8c4K0ibrdmcHSwonrb856TVep0Ne1cr21tOcmYmptgGco_vNsKvPsua0Hxff56_ikGDYonY5y7q6leFP5F9LAKUgRjPdhXM6OzdpHfP8XkiiPor9A1WWW0VhxmxCGe7dfQF_0QFYtmWnAymSS1PExUz4KdKGjPKtPanZe6ufym-5-ErSc-kH0mWi6AxvYt_5VQ

我们对头部和负载两个部分进行解码看一看。

头部：

{
  "x5t#S256": "SxqqdWYxT7BZrdH-uVpgAHfX2q34qPyxx4onX6mv-qI",
  "kid": "felord.cn",
  "alg": "RS256"
}

头部包含了常规的JWT Header信息，符合JOSE规范。

负载：

{
  "sub": "user",
  "aud": "e2fa7e64-249b-46f0-ae1d-797610e88615",
  "azp": "e2fa7e64-249b-46f0-ae1d-797610e88615",
  "iss": "http://localhost:9000",
  "exp": 1653625128,
  "iat": 1653623328,
  "nonce": "W6nKy9qfqV2DoH3uL5FTcU9EFGi8uijk-ep22WtFCcY"
}

从上面看，负载包含了一系列的claim，它们的含义如图：

在这里插入图片描述

如何进行OIDC认证

OIDC的认证流程主要是由OAuth2的几种授权流程扩展而来，有以下三种：

Authorization Code Flow 基于OAuth2授权码流程进行OIDC认证授权
~~Implicit Flow~~ 基于OAuth2隐匿流，由于OAuth2.1移除了隐匿流，所以这个应该也会被移除。
~~Hybrid Flow~~ 基于以上两者的混合流，也应该会被移除。

至于为什么没客户端凭据模式，是因为客户端凭据被设计用来做客户端之间的交互和End User根本没用半毛钱关系。所以重点就是Authorization Code Flow。

Authorization Code Flow

关于授权码流，其实我觉得没有什么可多说的，如果你是OIDC Authorization Code Flow，你必须在请求中的scope参数中携带openid，授权服务器收到请求后会多返回一个EU的用户信息ID Token。流程上和OAuth2授权码流程完全一样。

请注意，OIDC必须使用JWT作为令牌风格。

用户信息端点

OIDC还提供用户信息端点，这个端点是一个资源端点。它的请求方式为：

GET /userinfo HTTP/1.1
Host: localhost:9000
Authorization: Bearer eyJ4NXQjUzI1NiI6IlN4cXFkV1l4VDdCWnJkSC11VnBnQUhmWDJxMzRxUHl4eDRvblg2bXYtcUkiLCJraWQiOiJqb3NlIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJ1c2VyIiwiYXVkIjoiZTJmYTdlNjQtMjQ5Yi00NmYwLWFlMWQtNzk3NjEwZTg4NjE1IiwibmJmIjoxNjUzNTQ2OTUwLCJzY29wZSI6WyJvcGVuaWQiLCJtZXNzYWdlLnJlYWQiLCJtZXNzYWdlLndyaXRlIl0sImlzcyI6Imh0dHA6XC9cL2xvY2FsaG9zdDo5MDAwIiwiZXhwIjoxNjUzNTQ3MjUwLCJpYXQiOjE2NTM1NDY5NTB9.MxySV9FwP3JVdThc7DkoROfseEPW1fRXRD1ljWN05keCzwaiAwvRap-QyA5gYJewpid7fOFwnD5ETDns3-ia_QHRYp5RIPWnc-cb__9_JITTpLso_AiXpwxCr6TxrKt5Ax_jzkL9_MGrHQl7BqUpCAecc_NccS4WAR6pmIiNexAMrXusn2a5VodFxv18BpgRv_dJ9w_a3tmYXBWAC1apSoXXlpaI96NIprXOUnJWyKGlYS1VsXc6YMYArDBOamvtFD74L9UaTLCj1n5GU1FKlTGE061c07eKFk91O9IgOc5YR0Uzu-VNhea0NB5SlwImhUJSE4Ab11RlJD_eg0Oc9g

也可以是POST请求。基本的返回值为：

  HTTP/1.1 200 OK
  Content-Type: application/json

  {
   "sub": "felord.cn"
  }

如果你还想返回比如邮箱地址、头像、昵称、真实姓名之类的用户信息，需要携带额外的scope。

总结

OIDC还有很多东西，初学者掌握上面的基本功能即可，更多的功能需要参考OIDC官方文档。OIDC的用途比原生的OAuth2更加广泛，它是一个完全开放的标准，兼容了其它的一些IDP协议。后续在合适的时机，我会提到它们。