1、OIDC协议与OAuth2协议的区别

1.1 OAuth2 协议

我们在日常开发中，OAuth2协议可能接触比较多，例如用户权限系统集成Spring Security OAuth2进行身份授权认证；那什么是OAuth2协议？

OAuth 即 Open Authorization ，用于开放授权处理。OAuth 2.0是一个授权标准协议，可以使第三方应用获得对资源服务的有限访问。

根据 OAuth 2.0 协议规范，定义了四个角色：

• 资源所有者（Resource Owner）：能够授予对受保护资源访问权限的实体。例如应用的用户是资源的所有者，可以授权其他人访问他的资源。当资源所有者是一个人时，它被称为最终用户。 —— 就相当于 admin，控制授予 Access Token 何种权限

• 资源服务器（Resource Server）：存储受保护资源的服务器，能够接受并使用访问令牌来响应受保护的资源请求。就是资源服务器接受 Access Token，然后验证它拥有的权限，最后返回对应的资源。这个资源服务器一般是应用本身。—— 验证 Access Token 和相应的权限，并返回资源

• 授权服务器（Authorisation Server）：服务器向客户端（即应用）颁发访问令牌来验证资源所有者并获得授权。即负责颁发 Access Token 的服务器，例如 IDaaS 就是一个授权服务器。—— 向客户端发放 Access Token

• 客户端（Client）：需要获取访问令牌以访问资源服务器的应用。经过授权后，授权服务器为客户端颁发 Access Token。后续客户端可以携带这个 Access Token 到资源服务器那访问用户的资源。—— 需要 Access Token 来获取资源

在 OAuth 2.0 中一个应用可能既是 Resource Server，也是 Client，具体是什么角色，取决于应用工作的场景。且 OAuth 2.0 是关于授权而不是身份验证的。使用OAuth 2.0，客户端不知道终端用户是谁。它只需获取一个访问令牌，即可代表用户访问资源。

1.2 OIDC是什么？

OpenID Connect，也就是OIDC，它是建立在 OAuth 2.0协议之上的一个简单的身份层，它允许计算客户端根据授权服务器执行的认证，以 JSON 作为数据格式，验证终端用户的身份。它是 OpenID 的第三代规范，前面分别有 OpenID 和 OpenID 2.0。它在OAuth 2.0 的基础上增加了 ID Token来解决第三方客户端标识用户身份认证的问题。

因为OIDC是在OAuth2之上的协议，在 OAuth 2.0 之上实现了更多的标准，例如定义了一系列的 EndPoint 。还有一些规范诸如 Session Management，Front-Channel Logout，Back-Channel Logout 等。

OIDC 之所以有认证的功能，是因为在 OAuth 2.0 颁发 Access Token 的基础上，多颁发了一个 ID Token（用户的身份凭证）， Access Token 是一个随机字符串，不同的是，ID Token 是一个 JWT Token 。

ID Token 自身包含了一些用户的基本信息，而且由于 JWT 的防篡改性，让客户端不需要再向授权服务器进行身份验证，就能直接用 ID Token 来进行身份验证。即使 ID Token 包含的用户信息不够，也可以调用 OIDC 定义的 UserInfo EndPoint（用户信息接口）来获取更多的用户信息。

OIDC 协议定义的名词和 OAuth 2.0 协议定义的稍微有些出入：

• OpenID Provider ，简称 OP ：相当于 OAuth 2.0 中的授权服务器，除了负责颁发 Access Token ，还会颁发 ID Token 。例如 IDaaS 就是一个 OP 。

• Relying Party ，简称 RP ：代指 OAuth 2.0 中的客户端。

• End User ，简称 EU ：即用户。

从抽象的角度来看，OIDC的流程由以下5个步骤构成：

1. RP发送一个认证请求给OP；
2. OP对EU进行身份认证，然后提供授权；
3. OP把ID Token和Access Token（需要的话）返回给RP；
4. RP使用Access Token发送一个请求UserInfo EndPoint；
5. UserInfo EndPoint返回EU的Claims。
   

最后， OIDC 的授权流程与 OAuth 2.0 是一样的，主要区别在于 OIDC 授权流程中会额外返回 ID Token。

这里总结一下 OIDC 与 OAuth 2.0 的大致区别，如下图所示：

1.3 OIDC 协议族

OIDC本身是有多个规范构成，其中包含一个核心的规范，多个可选支持的规范来提供扩展支持，简单的来看一下：

1. Core：必选。定义OIDC的核心功能，在OAuth 2.0之上构建身份认证，以及如何使用Claims来传递用户的信息。
2. Discovery：可选。发现服务，使客户端可以动态的获取OIDC服务相关的元数据描述信息（比如支持那些规范，接口地址是什么等等）。
3. Dynamic Registration ：可选。动态注册服务，使客户端可以动态的注册到OIDC的OP。
4. OAuth 2.0 Multiple Response Types ：可选。针对OAuth2的扩展，提供几个新的response_type。
5. OAuth 2.0 Form Post Response Mode：可选。针对OAuth2的扩展，OAuth2回传信息给客户端是通过URL的querystring和fragment这两种方式，这个扩展标准提供了一基于form表单的形式把数据post给客户端的机制。
6. Session Management ：可选。Session管理，用于规范OIDC服务如何管理Session信息。
7. Front-Channel Logout：可选。基于前端的注销机制，使得RP可以不使用OP的iframe来退出。
8. Back-Channel Logout：可选。基于后端的注销机制，定义了RP和OP直接如何通信来完成注销。

上图是官方给出的一个OIDC组成结构图，我们暂时只关注Core的部分，其他的部分了解是什么东西就可以了，OIDC也不是新技术，它主要是借鉴OpenId的身份标识，OAuth2的授权和JWT包装数据的方式，把这些技术融合在一起就是OIDC。

1.4 OIDC认证

OIDC基于OAuth2，所以OIDC的认证流程主要是由OAuth2的几种授权流程延伸而来的，有以下3种：

• Authorization Code Flow：使用OAuth2的授权码来换取Id Token和Access Token。

1. EU 访问 RP 的资源但是没有进行身份认证
2. RP 将 EU redirect 到 OP 端，并带上一些参数，这里列举一些必选参数，还有许多可选参数可以看这里 client_id：唯一标识scope：请求权限范围，OIDC的请求必须包含值为“openid”的scope的参数response_type：要求 OP 的返回值，值为 code，token，id_token，none 中的一个或几个，在当前 flow 值为 coderedirect URL：认证完成后的跳转URLstate：当前登录认证操作的一个随机 query，用于防止 CSRF 或 XSRF 攻击
3. 然后 OP 会验证 EU 的身份信息，通常会询问用户是否将自己的信息提供给 RP，确认后进行登录操作
4. 登陆成功后 OP 会将 EU redirect 到刚刚 RP 提供的 URL，同时会在 URL 中带上一个 Authorization Code 和刚刚的 state 参数
5. 之后 RP 拿到 code 和 state，先确认是不是相同的 state 保证这次通信是有效的，之后再通过 POST 请求从 OP 获取 token，里面包含 ID Token，Access Token，Refresh Token，Token Type，Expired In 等信息
6. 之后 RP 会验证 ID Token 和验证 Access Token 确保它们没有问题
7. 然后 RP 通过 Access token 通过 OP 提供的 UserInfo Endpoint 获取用户信息，拿到用户信息后与自己的用户信息进行比对
8. 最后返回一个 APP Token 到 EU

• Implicit Flow：使用OAuth2的Implicit流程获取Id Token和Access Token。
  Implicit Flow 是在 OP redirect EU 到 RP 的时候会带上 ID Token 和 Access Token(如果必要) 而不是 Authorization Code，同时在发送请求的时候也会有一些不同，需要带上一些别的参数

• Hybrid Flow：混合Authorization Code Flow+Implici Flow。
  Hybrid Flow 可以理解为上面两个 flow 的结合，OP redirect EU 到 RP 的时候会带上 Authorization Code，同时根据发送请求时候 Response Type 参数的不同还会带上一些别的参数

2、总结

本篇博客介绍了OIDC的发现服务，OAuth2的扩展规范。OIDC其本身是一个完全开放的标准，而且兼容众多的已有的IDP（身份提供商），比如基于SAML的、基于WS-Federation的等等已有的身份认证系统，都可以作为OIDC的OP存在。总结一下OIDC有那些特性和好处吧：

• OIDC使得身份认证可以作为一个服务存在。
• OIDC可以很方便的实现SSO（跨顶级域）。
• OIDC兼容OAuth2，可以使用Access Token控制受保护的API资源。
• OIDC可以兼容众多的IDP作为OIDC的OP来使用。
• OIDC的一些敏感接口均强制要求TLS，除此之外，得益于JWT,JWS,JWE家族的安全机制，使得一些敏感信息可以进行数字签名、加密和验证，进一步确保整个认证过程中的安全保障。