在上一文里我们通过一个例子回顾了OAuth 2.0的流程，同时指出了OAuth 2.0的局限性：客户端无法认定资源拥有者就是正确的拥护者，虽然市面上的OAuth 2.0能够保证授权的安全性，但是OAuth 2.0本身并没有对用户认证提供明确的规范。这就是OIDC产生的契机。
❝ OIDC是OAuth 2.0的一个变种。
OIDC（OpenID Connect）建立在Auth 2.0的流程之上，提出了终端用户认证标识ID Token概念。符合OIDC流程的一定符合OAuth2.0。OAuth 2.0 是关于如何发布访问令牌（AccessToken）的规范；而OIDC是关于如何发布ID 令牌的规范。虽然这两种令牌都是以JWT的形式体现。
在RFC 6749中定义的一个OAuth2.0授权端点（authorization endpoint） 用以请求授权，该端点需要一个<code>response_type</code>的参数用来通知授权服务器所需的授权类型，通常包括了<code>code</code>和<code>token</code>两种。OIDC扩展了这一属性，增加了<code>id_token</code>和<code>none</code>。那么<code>response_type</code>的值现在可能有下列组合的情况：
<code>code</code>
<code>token</code>
<code>id_token</code>
<code>code token</code>
<code>id_token token</code>
<code>code id_token</code>
<code>code id_token token</code>
<code>none</code>
另外如果该请求是一个OIDC授权认证请求还必须包含一个值为<code>openid</code> 的<code>scope</code>参数，这是区分普通OAuth 2.0和OIDC的关键。
OIDC规定了一些术语用来提高我们学习的门槛:
<code>EU</code>：End User 终端用户
<code>RP</code>：Relying Party 即客户端（client），授权和认证的最终消费方，我搞不懂为啥要玩多余的概念
<code>OP</code>：OpenID Provider，对EU进行认证的服务提供者
<code>ID Token</code>：JWT格式，EU的认证通过后生成凭证，供RP消费
<code>UserInfo Endpoint</code>：通过凭据查询用户基本信息的接口，建议上HTTPS。
OIDC复用了OAuth2.0的授权流程，在授权的过程中增加了一些“小动作”来进行用户认证。结合其术语，大致的流程是这样的：
RP发送一个认证请求给OP；
OP先对EU进行身份认证，确认无误后提供授权；
OP把ID Token和Access Token（需要的话）返回给RP；
RP使用Access Token发送一个请求UserInfo EndPoint；（可选）
UserInfo EndPoint返回EU的Claims。（基于第4个步骤可选）
OIDC协议流程图
另外，OIDC归纳了三种复用OAuth 2.0的流程：
Authorization Code Flow：使用OAuth2的<code>Authorization Code</code>模式来换取Id Token和Access Token。
Implicit Flow：使用OAuth2的<code>Implicit</code>模式获取Id Token和Access Token。
Hybrid Flow：以上两种的混合实现。
协议这个东西学起来确实比较枯燥难懂，需要结合一些场景才能说清楚，说实话有些东西我也云里雾里，不过这个是无法跳过去的东西。先不要想太多为什么，后续会结合一些场景来搞明白上面的术语和流程。