OAuth2.0  与  OIDC
简述
OAuth2.0
OAuth2.0是一种用于访问授权的行业标准协议，OAuth2.0用于为互联网用户提供将其在某个网站的信息授权给其他第三方应用、网站访问，但是不需要将网站的账号密码给第三方应用、网站。

举个例子：

我在Github上有一个账号，现在我要访问其他网站如leetcode.cn，但又不想在LeetCode上重新填入各种身份信息创建账号。那能否复用我在github.com上的一些信息数据？

如果github.com和leetcode.cn实现了OAuth2.0协议，那么我就可以授权leetcode.cn到github.com上访问我的在github.com上的基本账户信息（如用户名、头像、邮箱、手机号）等。

OIDC-OpenID  Connect
OIDC，即OpenID  Connect。

OpenID  Connect  是基于OAuth  2.0的身份认证协议，增加了Id  Token。

OIDC是OAuth2.0的超集，可以理解为OIDC=身份认证+OAuth2.0. 

OAuth2.0主要定义了资源的授权，而OIDC主要关注的是身份的认证。（身份信息也属于资源，但是OAuth2.0中没有对身份信息包含哪些内容以及认证过程做完整定义）

举个例子：

我有一个google账号，我会使用许多google系的应用，如Gmail、Chrome等。通过ODIC（可能是定制版本），我可以使用同一个google账号去登录这些google系应用（以及以google作为身份提供商的第三方应用）。甚至这些应用间可以以Goolge账号系统提供的ID  Token来认证是不是同一个用户。 

OAuth2.0
角色定义
OAuth2.0  中包含四个角色

资源拥有者-Resource  Owner：  能够授予对受保护资源的访问权限的实体。当资源所有者是人员时，它被称为最终用户。
资源服务器-Resource  Server：  托管受保护资源的服务器，能够接受并使用访问令牌响应受保护的资源请求。
客户端-client：  代表资源所有者在其授权下，发起受保护资源请求的应用程序。
授权服务器-Authorization  Server：  服务器在成功对资源所有者进行身份验证并获得授权后向客户端颁发访问令牌。
在互联网系统场景下：

资源拥有者通常是网站的最终用户

资源服务器和授权服务器通常是同一个网站/应用里的子系统/模块，如微信中的数据库模块和认证模块。

客户端-client通常是一些第三方网站/应用，如微信里的小程序。

运行流程
evernotecid://7D20C308-3D50-459D-A54D-B87FB1FC2C81/appyinxiangcom/11494076/ENResource/p1015


(A):  client  向  Resource-Owner  请求认证授权。
(B):  client  获得  Resource-Owner  授权的凭据。
(C):  client  通过向  Authorition-Server  进行身份验证并显示授权来请求访问令牌Access  Token。
(D):  client  获得  Access  Token
(E):  client  使用前面获得的  Access  Token  请求被保护的资源
(F):  client  获得  被保护的资源
在OAuth2.0的运行流程中，

(C)->(F)实现相对单一，就是后台获取Access  Token，以及用Access  Token来访问资源。

(A)->(B)则有比较大的操作空间，如果请求Resource-Owner的授权,以及获得的是什么样的凭据，可以根据场景需要来实现。

四种授权模式
OAuth  2.0定义了四种授权方式

授权码模式（authorization  code）
简化模式（implicit）
密码模式（resource  owner  password  credentials）
客户端模式（client  credentials）
授权码模式  authorization  code
授权码模式是最常用、最安全的授权方式，适用于有后端的Web应用。

授权码模式的基本原理是：

client  不直接向Resource  Owner请求授权，而是利用Authorization  Server作为一个中间媒介，

client将Resource  Owner引导至Authorization  Server的页面（会带上client的页面地址）。
Resource  Owner在Authorization  Server的页面完成认证后，生成authorization  code重定向回client页面。
以上即完成OAuth2.0运行流程中的(A)->(B),  client有了Authorization  Server提供的凭据authorization  code即可进行后续动作，请求Access  Token
简化模式implicit
简化模式是将OAuth2.0运行流程中的(A)->(B),  (C)->(D)两次交互合并成一次交互，即client不获取authorization  code，  而是再第一次交互直接获取Access  Token.

简化模式中获取Access  Token的过程和授权码模式中获取authorization  code相似。

密码模式resource  owner  password  credentials
密码模式是Resource  Owner直接向client提供账号密码，client使用账号密码来向Authorization  Server请求Access  Token

密码模式适用于client高度可信的场景。

客户端模式client  credentials
客户端模式指：客户端以自己的名义，而不是以Resource  Owner的名义，向authorization  Server进行请求授权。这里就不存在Resource  Owner的授权了。 

OpenID  Connect  ——  OIDC
OpenID  Connect协议族  及其依赖的基础如下图所示：

evernotecid://7D20C308-3D50-459D-A54D-B87FB1FC2C81/appyinxiangcom/11494076/ENResource/p1017


OpenID使用OAuth2.0作为其授权协议，在此基础上定义了身份认证的过程。

OpenID运行流程
evernotecid://7D20C308-3D50-459D-A54D-B87FB1FC2C81/appyinxiangcom/11494076/ENResource/p1016


RP（客户端）向OP（OpenID  Provider）  发送请求。
OP  对最终用户进行身份验证并获取授权。
OP  使用  ID-Token（通常为访问令牌）进行响应。
RP  可以使用访问令牌将请求发送到用户信息终结点。
用户信息终结点返回有关最终用户的claim。
OIDC的核心在于授权过程中，一并提供用户的身份认证信息ID-Token(使用JWT来包装）给到第三方客户端，OP通常还提供了GetUserInfo的接口，用于获取用户更完整的信息。

OpenID  Provider
OpenID  Provider  是OpenID  Connect最关键的组件。

大型的互联网厂商（其本身就用几十个上百个应用需要打通账号、单点登录）
独立的专门提供OIDC服务的厂商
自建