微服务-微服务Spring Security OAuth 2实战

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 支持搭建授权服务器和资源服务器
• 课程：27-微服务安全Spring Security OAuth2实战一

Springboot3.x Oauth2实现：

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

3. OAuth2.0协议介绍

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

OAuth2.0协议：RFC 6749 - The OAuth 2.0 Authorization Framework

3.1 角色

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

3.2 OAuth2.0协议的运行流程

OAuth 2.0的运行流程如下图，摘自RFC 6749：

（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/前端

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

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

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

客户端模式

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

它的步骤如下：

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

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

客户端模式的时序图如下：

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）后，就可以带着令牌去访问资源服务器了。

实现效果

> 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&re

sponse_type=token&scope=message.read&redirect_uri=http://www.baidu.com ，注意，此时参数不需 要 client_secret 。

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

6 ：用户在授权页面选择授权范围，点击确认提交，则带上客户端参数和用户授权范围向认证服务器获 取令牌（access_token