2、Spring Security Oauth2

1. Spring Authorization Server 是什么

Spring Authorization Server 是一个框架，它提供了 OAuth 2.1 和 OpenID Connect 1.0 规范以及其他相关规范的实现。它建立在 Spring Security 之上，为构建 OpenID Connect 1.0 身份提供者和 OAuth2 授权服务器产品提供了一个安全、轻量级和可定制的基础。说白了，Spring Authorization Server 就是一个认证（授权）服务器。

官方主页：Spring Authorization Server

2. 为什么有 Spring Authorization Server 

因为随着网络和设备的发展，原先的 OAuth 2.0 已经不能满足现今的需求了，OAuth 社区对 OAuth 2.0 中的几种授权模式进行了取舍和优化，并增加一些新的特性， 于是推出了 OAuth 2.1，而原先的 Spring Security OAuth 2.0 使用的是 OAuth 2.0 协议，为满足新的变化，Spring Security 团队重新写了一套叫 Spring Authorization Server 的认证授权框架来替换原先的 Spring Security OAuth 2.0。从官网中可以看到，原先的 Spring Security OAuth 2.0 已从 Spring Security 目录下被移除，接着是多出 Spring Authorization Server 作为单独项目。 

Springboot2.x Oauth2实现：

• Spring Security Oauth2 支持搭建授权服务器和资源服务器

Springboot3.x Oauth2实现：

• Spring Security6 自身提供资源和客户端类库支持
• Spring Authorization Server支持授权服务器搭建

3. OAuth2.0协议介绍 

OAuth 2.0 （Open Authorization）是一种开放标准的授权协议，允许用户授权第三方应用访问其在某个服务提供者上的受保护资源，而无需将其实际的凭证（如用户名和密码）分享给第三方应用。这种方式可以增加安全性，同时允许用户更好地控制其数据的访问权限。

OAuth2.0协议：https://datatracker.ietf.org/doc/html/rfc6749

3.1 角色 

• 客户端（client）：使用授权服务器作为认证渠道的平台，一般指的是第三方应用。例如，微信提供 OAuth 2.0 认证平台，我们的 APP 支持微信登录，那么我们的 APP 对于微信服务来说就是客户端。又例如，我们是政府某一平台的服务，我们平台维护的数据代表着足够高的权威，那么其他政府部门或合作方，需要从我们的平台中查询数据，或者利用我们平台的认证进行登录，那么其他部门或合作方的应用就是客户端。
• 资源服务器（resource server）：简单的说，就是提供接口给客户端访问的服务器，访问资源服务器上受保护的接口，则需要带上令牌（token）。例如分布式微服务中的用户服务、订单服务等部署的服务器都属于资源服务器。
• 资源所有者（resource owner）：拥有该资源的主体对象，一般指用户。客户端向资源服务器请求获取用户数据时，资源所有者参与确认授权或拒绝操作。
• 授权服务器（authorization server）：对客户端和用户进行身份认证、授权的服务器，认证授权成功，则颁发令牌（token）。

 3.2 OAuth2.0协议的运行流程

OAuth 2.0的运行流程如下图， 

   (A）用户打开客户端以后，客户端要求用户给予授权。

（B）用户同意给予客户端授权。

（C）客户端使用上一步获得的授权，向授权服务器申请令牌。

（D）授权服务器对客户端进行认证以后，确认无误，同意发放令牌。

（E）客户端使用令牌，向资源服务器申请获取资源。

（F）资源服务器确认令牌无误，同意向客户端开放资源。

令牌（token）与密码（password）的作用是一样的，都可以进入系统，但是有三点差异。

（1）令牌是短期的，到期会自动失效，用户自己无法修改。密码一般长期有效，用户不修改，就不会发生变化。

（2）令牌可以被数据所有者撤销，会立即失效。密码一般不允许被他人撤销。

（3）令牌有权限范围（scope）。对于网络服务来说，只读令牌就比读写令牌更安全。密码一般是完整权限。

上面这些设计，保证了令牌既可以让第三方应用获得权限，同时又随时可控，不会危及系统安全。这就是 OAuth 2.0 的优点。

3.3 应用场景 

OAuth 2.0 在许多不同的应用场景中都能够发挥作用，尤其是那些涉及到第三方应用程序访问用户数据或资源的情况。以下是一些常见的 OAuth 2.0 应用场景：

• 社交媒体登录：许多网站和应用程序允许用户使用其社交媒体账户（如Facebook、Google、Twitter等）进行登录。OAuth 2.0 可以用于授权第三方应用访问用户的社交媒体数据，如好友列表、社交活动等。
• 第三方应用集成：用户可能使用多个不同的应用和服务，例如电子邮件、日历、云存储等。OAuth 2.0 可以用于实现单一的登录授权，使用户能够在多个应用之间共享数据，而无需在每个应用中都输入凭证。
• 移动应用访问 API：移动应用可能需要访问后端服务器上的受保护资源，例如用户数据或其他服务。OAuth 2.0 可以确保安全地进行授权和访问控制，同时减少对用户凭证的需求。
• 授权访问云服务：当用户需要将他们的数据存储在云服务（如Google Drive、Dropbox）中时，OAuth 2.0 可以确保这些服务只能以授权的方式访问用户的数据。
• API 访问控制：企业和开发者可以使用 OAuth 2.0 来实现对其 API 的访问控制。只有经过授权的应用程序才能访问和使用这些 API。
• 联合身份验证：在不同的身份提供者之间实现联合身份验证，使用户可以使用一个身份提供者的凭证来访问另一个身份提供者的资源。
• 医疗保健应用：在医疗保健领域，患者的健康数据可能由多个医疗应用和机构共享。OAuth 2.0 可以用于确保授权的数据访问，同时保护患者隐私。
• IoT 设备访问：物联网设备可能需要访问云服务或其他资源。OAuth 2.0 可以用于在 IoT 设备和云之间实现安全的授权流程。

这些只是 OAuth 2.0 可能应用的一些例子。基本上，任何需要实现安全的第三方应用程序访问用户数据或资源的情况下，OAuth 2.0 都可能是一个合适的解决方案。

3.4 授权模式详解

授权码模式：应用最广泛，适合web应用/app/前端

资源所有者密码模式：官方应用

客户端凭证模式：适合无用户参与的应用

刷新令牌模式：适合令牌访问过期后刷新令牌

客户端模式 

        客户端模式指客户端以自己的名义，而不是以用户的名义，向服务提供商进行授权。客户端模式是安全级别最低而且要求授权服务器对客户的高度信任的模式。因为客户端向授权服务器请求认证授权的过程中，自始至终都没有用户的参与，未经过用户允许，客户端凭通过自己在授权服务器注册的信息即可在授权服务器完成认证授权，而客户端获取到认证授权以后，则拥有资源服务器操作用户数据的权限，这种模式一般应用于公司内部系统或者有着高度保密责任的合作伙伴之间的对接。

 它的步骤如下：

        客户端向授权服务器进行身份认证，并要求一个访问令牌

          授权服务器确认无误后，向客户端提供访问令牌

客户端模式的时序如下：

1：客户端首先在认证服务器注册好客户端信息。

2：认证服务器存储维护客户端信息。

3：客户端带上 client_id、client_secret、grant_type（写死client_credentials）等参数向认证服务器发起获取 token 请求。

4：认证服务器校验客户端信息，校验通过，则发放令牌（access_token），校验失败，则返回异常信息。

5：客户端成功获取到令牌（access_token）后，就可以带着令牌去访问资源服务器了。

实现效果

1. A 应用在命令行向 B 发出请求。

> https://oauth.b.com/token?
>   grant_type=client_credentials&
>   client_id=CLIENT_ID&
>   client_secret=CLIENT_SECRET

2. B 网站验证通过以后，直接返回令牌。

密码模式

如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码模式"（password）。

密码模式是一种安全级别较低而且要求资源拥有者（用户）完全信任客户端的模式，该模式可以理解为在客户端模式的基础上增加了对用户的账号、密码在认证服务器进行校验的操作，是客户端代理用户的操作。在 OAuth 2.1 中，密码模式已经被废除，在第三方平台上，使用密码模式，对于用户来说是一种非常不安全的行为，假设某平台客户端支持 QQ 登录，用户使用自己 QQ 的账号、密码在该平台上输入进行登录，则该平台将拥有用户 QQ 的账号、密码，对于用户来说，将自己 QQ 的账号、密码提供给第三方平台，这种行为是非常不安全的。

密码模式一般适合应用在自己公司内部使用的系统和自己公司的 app 产品，例如一些 ERP、CRM、WMS 系统，因为都是自己公司的产品，这种情况下就不存在用户提供账号、密码给第三方客户端进行代理登录的情形了。

它的步骤如下：

（A）用户向客户端提供用户名和密码。

（B）客户端将用户名和密码发给授权服务器，向后者请求令牌。

（C）授权服务器确认无误后，向客户端提供访问令牌。

密码模式的时序图如下：

1：客户端首先在认证服务器注册好客户端信息。

2：认证服务器存储维护客户端信息。

3：用户提供认证平台的账号、密码给客户端（这里的客户端可以是浏览器、APP、第三方应用的服务器）。

4：客户端带上 client_id、client_secret、grant_type（写死password）、username、password 等参数向认证服务器发起获取 token 请求。

5：认证服务器校验客户端信息，校验失败，则返回异常信息,校验通过，则往下继续校验用户验账号、密码。

6：认证服务器校验用户账号、密码，校验通过，则发放令牌（access_token），校验失败，则返回异常信息。

7：客户端成功获取到令牌（access_token）后，就可以带着令牌去访问资源服务器了。

实现效果

1. A 网站要求用户提供 B 网站的用户名和密码，拿到以后，A 就直接向 B 请求令牌。整个过程中，客户端不得保存用户的密码。

> https://oauth.b.com/token? > grant_type=password& # 授权方式是"密码模式" > username=USERNAME& > password=PASSWORD& > client_id=CLIENT_ID > client_secret=client_secret

2. B 网站验证身份通过后，直接给出令牌。注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 因此拿到令牌。

授权码模式

授权码（authorization code）方式，指的是第三方应用先申请一个授权码，然后再用该授权码获取令牌。

授权码模式是 OAuth 2.0 协议中安全级别最高的一种认证模式，他与密码模式一样，都需要使用到用户的账号信息在认证平台的登录操作，但有所不同的是，密码模式是要求用户直接将自己在认证平台的账号、密码提供给第三方应用（客户端），由第三方平台进行代理用户在认证平台的登录操作；而授权码模式则是用户在认证平台提供的界面进行登录，然后通过用户确认授权后才将一次性授权码提供给第三方应用，第三方应用拿到一次性授权码以后才去认证平台获取 token。

适用场景：目前市面上主流的第三方验证都是采用这种模式

它的步骤如下：

（A）用户访问客户端，后者将前者导向授权服务器。

（B）用户选择是否给予客户端授权。

（C）假设用户给予授权，授权服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。

（D）客户端收到授权码，附上早先的"重定向URI"，向授权服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。

（E）授权服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

授权码模式的时序图如下：

1：客户端首先在认证服务器注册好客户端信息。

2：认证服务器存储维护客户端信息。

3：用户在客户端上发起登录。

4：向认证服务器发起认证授权请求，例如http://localhost:9000/auth/oauth/authorize?client_id=xxx&response_type=code&scope=message.read&redirect_uri=http://www.baidu.com，注意，此时参数不需要client_secret。

5：认证服务器带上客户端参数，将操作引导至用户授权确认页面，用户在该页面进行授权确认操作。

6：用户在授权页面选择授权范围，点击确认提交，则带上客户端参数和用户授权范围向认证服务器获取授权码。注意，此处操作已经脱离了客户端。

7：认证服务器校验客户端信息和授权范围（因为客户端在认证平台注册的时候，注册信息包含授权范围，如果用户选择的授权范围不在注册信息包含的范围内，则将因权限不足返回失败）。

8：校验通过，将授权码拼接到客户端注册的回调地址返回给客户端。

9：客户端拿到认证服务器返回的授权码后，带上客户端信息和授权码向认证服务器换取令牌（access_token）。

10：认证服务器校验授权码是否有效，如果有效，则返回令牌（access_token）；如果无效，则返回异常信息。

11：客户端成功获取到令牌（access_token）后，就可以带着令牌去访问资源服务器了。

实现效果

1. A网站提供一个链接，用户点击后就会跳转到 B 网站，授权用户数据给 A 网站使用。下面就是 A 网站跳转 B 网站的一个示意链接。

> https://b.com/oauth/authorize? > response_type=code& #要求返回授权码（code） > client_id=CLIENT_ID& #让 B 知道是谁在请求 > redirect_uri=CALLBACK_URL& #B 接受或拒绝请求后的跳转网址 > scope=read # 要求的授权范围（这里是只读） >

客户端申请授权的URI，包含以下参数：

• response_type：表示授权类型，必选项，此处的值固定为"code"
• client_id：表示客户端的ID，必选项
• redirect_uri：表示重定向URI，可选项
• scope：表示申请的权限范围，可选项
• state：表示客户端的当前状态，可以指定任意值，授权服务器会原封不动地返回这个值。

2. 用户跳转后，B 网站会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时 B 网站就会跳回redirect_uri参数指定的网址。跳转时，会传回一个授权码，就像下面这样。

> https://a.com/callback?code=AUTHORIZATION_CODE #code参数就是授权码 >

3. A 网站拿到授权码以后，就可以在后端，向 B 网站请求令牌。 用户不可见，服务端行为

> https://b.com/oauth/token? > client_id=CLIENT_ID& > client_secret=CLIENT_SECRET& # client_id和client_secret用来让 B 确认 A 的身份,client_secret参数是保密的，因此只能在后端发请求 > grant_type=authorization_code& # 采用的授权方式是授权码 > code=AUTHORIZATION_CODE& # 上一步拿到的授权码 > redirect_uri=CALLBACK_URL # 令牌颁发后的回调网址 >

4. B 网站收到请求以后，就会颁发令牌。具体做法是向redirect_uri指定的网址，发送一段 JSON 数据。

{ "access_token":"ACCESS_TOKEN", # 令牌 "token_type":"bearer", "expires_in":2592000, "refresh_token":"REFRESH_TOKEN", "scope":"read", "uid":100101, "info":{...} }

简化模式

简化模式（也叫隐式模式）是相对于授权码模式而言的，对授权码模式的交互做了一下简化，省去了客户端使用授权码去认证服务器换取令牌（access_token）的操作，即用户在代理页面选择授权范围提交授权确认后，认证服务器通过客户端注册的回调地址直接就给客户端返回令牌（access_token）了。

这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。

它的步骤如下：

（A）客户端将用户导向授权服务器。

（B）用户决定是否给于客户端授权。

（C）假设用户给予授权，授权服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌。

（D）浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。

（E）资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌。

（F）浏览器执行上一步获得的脚本，提取出令牌。

（G）浏览器将令牌发给客户端。

简化模式时序图如下：

1：客户端首先在认证服务器注册好客户端信息。

2：认证服务器存储维护客户端信息。

3：用户在客户端上发起登录。

4：向认证服务器发起认证授权请求，例如http://localhost:9000/auth/oauth/authorize?client_id=xxx&response_type=token&scope=message.read&redirect_uri=http://www.baidu.com，注意，此时参数不需要 client_secret。

5：认证服务器带上客户端参数，将操作引导至用户授权确认页面，用户在该页面进行授权确认操作。

6：用户在授权页面选择授权范围，点击确认提交，则带上客户端参数和用户授权范围向认证服务器获取令牌（access_token）。注意，此处操作已经脱离了客户端。

7：认证服务器校验代理页面提交的参数信息，校验通过，则将令牌（access_token）拼接到客户端注册的回调地址返回给客户端；校验失败，则返回异常信息。

8：客户端成功获取到令牌（access_token）后，就可以带着令牌去访问资源服务器了。

实现效果

1. A 网站提供一个链接，要求用户跳转到 B 网站，授权用户数据给 A 网站使用。

> https://b.com/oauth/authorize? > response_type=token& # response_type参数为token，表示要求直接返回令牌 > client_id=CLIENT_ID& > redirect_uri=CALLBACK_URL& > scope=read >

2. 用户跳转到 B 网站，登录后同意给予 A 网站授权。这时，B 网站就会跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站。

> https://a.com/callback#token=ACCESS_TOKEN #token参数就是令牌，A 网站直接在前端拿到令牌。 >

token刷新模式

令牌的有效期到了，如果让用户重新走一遍上面的流程，再申请一个新的令牌，很可能体验不好，而且也没有必要。OAuth 2.0 允许用户自动更新令牌。token刷新模式是对 access_token 过期的一种补办操作，这种补办操作，减少了用户重新操作登录的流程。OAuth 2.0 在给客户端颁发 access_token 的时候，同时也给客户端发放了 refresh_token，而 refresh_token 的有效期要远大于 access_token 的有效期。当客户端带着已过期的 access_token 去访问资源服务器中受保护的资源时，将会访问失败，此时就需要客户端使用 refresh_token 去获取新的 access_token。客户端端获取到新的 access_token 后，就可以带上他去访问资源服务器中受保护的资源了。

token 刷新模式时序图如下：

1：客户端向认证服务器请求认证授权。

2：认证服务器存返回 access_token、refresh_token、授权范围、过期时间。

3：access_token 过期后，客户端仍旧带着过期的 access_token 去请求资源服务器中受保护的资源。

4：资源服务器提示客户端，这是非法的 access_token。

5：客户端使用 refresh_token 向认证服务器获取新的 access_token。

6：认证服务器校验 refresh_token 的有效性，校验通过，则给客户端颁发新的 access_token；校验失败，则返回异常信息。

7：客户端成功获取到新的 access_token 后，就可以带着新的 access_token 去访问资源服务器了。

具体方法是，B 网站颁发令牌的时候，一次性颁发两个令牌，一个用于获取数据，另一个用于获取新的令牌（refresh token 字段）。令牌到期前，用户使用 refresh token 发一个请求，去更新令牌。

> https://b.com/oauth/token? > grant_type=refresh_token& # grant_type参数为refresh_token表示要求更新令牌 > client_id=CLIENT_ID& > client_secret=CLIENT_SECRET& > refresh_token=REFRESH_TOKEN # 用于更新令牌的令牌 >

4. OAuth 2.1 协议介绍

OAuth 2.1去掉了OAuth2.0中的密码模式、简化模式，增加了设备授权码模式，同时也对授权码模式增加了PKCE扩展。

OAuth2.1协议：draft-ietf-oauth-v2-1-07

OAuth 2.1 的变化： 有道云笔记

4.1 授权码模式+PKCE扩展 

授权码模式交互过程，见之前 OAuth2.0 授权码模式的讲解。这里要说的是授权码模式如何拓展 PKCE（ Proof Key for Code Exchange 代码交换验证密钥）。

在授权码模式的交互工程中，有一个环节比较薄弱，这个环节就是用户在代理页面确认授权的时候，容易受到恶意程序的攻击，从而导致授权码被恶意程序窃取，进而通过授权码窃取令牌，当然这个前提也需要恶意程序已经植入到你的PC或手机当中。首先，来看一下官网中描述的恶意程序拦截攻击授权码的交互图：

（1）客户端向认证服务器发起获取授权码请求时，跳转至授权确认页面，用户通过用浏览器在授权页面进行授权确认。

（2）授权页面向认证服务器提交客户端参数和授权范围。

（3）认证服务器将授权码拼接在客户端注册的回调地址中返回给客户端。

（4）在步骤（3）认证服务器返回授权码的过程中，如果恶意程序截取到授权码，那么他接下来就可以继续操作步骤（5）、步骤（6）了。

为了减轻这种攻击，官方增加PKCE扩展，先来看一下官方的交互图：

A. 客户端通过“/oauth2/authorize”地址向认证服务器发起获取授权码请求的时候增加两个参数，即 code_challenge 和 code_challenge_method，其中，code_challenge_method 是加密方法（例如：S256 或 plain），code_challenge 是使用 code_challenge_method 加密方法加密后的值。

B. 认证服务器给客户端返回授权码，同时记录下 code_challenge、code_challenge_method 的值。

C. 客户端使用 code 向认证服务器获取 Access Token 的时候，带上 code_verifier 参数，其值为步骤A加密前的初始值。

D. 认证服务器收到步骤 C 的请求时，将 code_verifier 的值使用 code_challenge_method 的方法进行加密，然后将加密后的值与步骤A中的 code_challenge 进行比较，看看是否一致。

上面交互过程中，恶意程序如果在B处截获授权码后，使用授权码向认证服务器换取 Access Token，但由于恶意程序没有 code_verifier 的值，因此在认证服务器无法校验通过，从而获取 Access Token 失败。

对于如何创建 code_challenge 的值，官网给出了下面两种对应的方法。

• plain code_challenge = code_verifier 0.3.0被废弃了
• S256 code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

4.2 设备授权码模式

设备授权码模式，是一种为解决不便在当前设备上进行文本输入而提供的一种认证授权模式，例如：智能电视、媒体控制台、数字相框、打印机等。大家也可以脑补一下一些扫码登录的情形。使用设备授权码模式，有以下要求。

(1) 该设备已连接到互联网。

(2) 设备能够支持发出 HTTPS 请求。

(3) 设备能够显示或以其他通信方式将 URI 和 Code 发给用户。

(4) 用户有辅助设备(如个人电脑或智能手机)，他们可以从中处理请求。

设备授权码登录官网交互图如下：

(A) 客户端带上包含客户端信息的参数向认证服务器（地址：/oauth2/device_authorization）发起授权访问。

(B) 认证服务器给客户端返回设备码、用户码及需要用户验证用户码的 URI。

(C) 客户端指示用户需要在另一设备进行访问授权的URI和用户码。

(D) 用户根据URI打开页面，输入用户码和确认授权，向认证服务器发起认证请求。

(E) 客户端在完成步骤（C）之后就开始带上客户端信息和设备码向认证服务器轮询获取令牌信息。

(F) 认证服务器收到客户端使用设备码获取令牌信息的请求后，检查用户是否已提交授权确认，如果用户已提交授权确认，则返回令牌信息。

时序图如下：

4.3 拓展授权模式

OAuth2.1 也提供拓展授权模式的操作实现。虽然 OAuth2.1 移除了密码模式（password），但是通过拓展授权模式可以实现密码模式。在实际应用中，客户端、授权服务器、资源服务器往往都是同一家公司的产品，那么这个时候，使用账号、密码进行登录的情形也比较常见，此时就需要通过拓展授权模式来实现账号、密码登录了。

拓展授权模式官网文档： How-to: Implement an Extension Authorization Grant Type

5. OpenID Connect 1.0协议

OpenID Connect 1.0：Final: OpenID Connect Core 1.0 incorporating errata set 1

OpenID Connect 1.0 是 OAuth 2.0 协议之上的一个简单的身份层。其实就是客户端向认证服务器请求认证授权的时候，多返回一个 id_token，该 id_token 是一串使用 jwt 加密过的字符串，如下如所示：

OpenID Connect协议在抽象上遵循以下步骤。

1. RP（客户端）向OpenID提供程序（OP）发送请求。
2. OP对最终用户进行身份验证并获得授权。
3. OP响应ID令牌和通常的访问令牌。
4. RP可以发送带有访问令牌的请求到用户信息端点。
5. 用户信息端点返回有关最终用户的声明。

6. Spring Authorization Server 实战

4.2 设备授权码模式

设备授权码模式，是一种为解决不便在当前设备上进行文本输入而提供的一种认证授权模式，例如：智能电视、媒体控制台、数字相框、打印机等。大家也可以脑补一下一些扫码登录的情形。使用设备授权码模式，有以下要求。

(1) 该设备已连接到互联网。

(2) 设备能够支持发出 HTTPS 请求。

(3) 设备能够显示或以其他通信方式将 URI 和 Code 发给用户。

(4) 用户有辅助设备(如个人电脑或智能手机)，他们可以从中处理请求。

设备授权码登录官网交互图如下：

(A) 客户端带上包含客户端信息的参数向认证服务器（地址：/oauth2/device_authorization）发起授权访问。

(B) 认证服务器给客户端返回设备码、用户码及需要用户验证用户码的 URI。

(C) 客户端指示用户需要在另一设备进行访问授权的URI和用户码。

(D) 用户根据URI打开页面，输入用户码和确认授权，向认证服务器发起认证请求。

(E) 客户端在完成步骤（C）之后就开始带上客户端信息和设备码向认证服务器轮询获取令牌信息。

(F) 认证服务器收到客户端使用设备码获取令牌信息的请求后，检查用户是否已提交授权确认，如果用户已提交授权确认，则返回令牌信息。

时序图如下：

4.3 拓展授权模式

OAuth2.1 也提供拓展授权模式的操作实现。虽然 OAuth2.1 移除了密码模式（password），但是通过拓展授权模式可以实现密码模式。在实际应用中，客户端、授权服务器、资源服务器往往都是同一家公司的产品，那么这个时候，使用账号、密码进行登录的情形也比较常见，此时就需要通过拓展授权模式来实现账号、密码登录了。

拓展授权模式官网文档： How-to: Implement an Extension Authorization Grant Type

5. OpenID Connect 1.0协议

OpenID Connect 1.0：Final: OpenID Connect Core 1.0 incorporating errata set 1

OpenID Connect 1.0 是 OAuth 2.0 协议之上的一个简单的身份层。其实就是客户端向认证服务器请求认证授权的时候，多返回一个 id_token，该 id_token 是一串使用 jwt 加密过的字符串，如下如所示：

OpenID Connect协议在抽象上遵循以下步骤。

1. RP（客户端）向OpenID提供程序（OP）发送请求。
2. OP对最终用户进行身份验证并获得授权。
3. OP响应ID令牌和通常的访问令牌。
4. RP可以发送带有访问令牌的请求到用户信息端点。
5. 用户信息端点返回有关最终用户的声明。

6. Spring Authorization Server 实战