1. 简介

1.1 什么是Oauth2

OAuth（开放授权）是一个开放标准，允许用户授权第三方移动应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容，OAuth2.0 是 OAuth 协议的延续版本，但不向后兼容 OAuth 1.0 即完全废止了 OAuth1.0。

应用场景：QQ登录、微信登录
参考：https://baike.baidu.com/item/oAuth/7153134?fr=aladdin
Oauth 协议：https://tools.ietf.org/html/rfc6749

1.2 核心概念

角色：

  • 客户端：本身不存储资源，需要通过资源拥有者的授权去请求资源服务器的资源，比如：Android客户端、Web客户端（浏览器端）、微信客户端等。
  • 资源拥有者：通常为用户，也可以是应用程序，即该资源的拥有者。
  • 授权服务器：用来对资源拥有的身份进行认证、对访问资源进行授权。客户端要想访问资源需要通过认证服务器由资源拥有者授权后方可访问。
  • 资源服务器：存储资源的服务器，比如，网站用户管理服务器存储了网站用户信息，网站相册服务器存储了用户的相册信息，微信的资源服务存储了微信的用户信息等。客户端最终访问资源服务器获取资源信息。

常用术语：

  • 客户凭证 (client Credentials) ：客户端的 clientId 和密码用于认证客户。
  • 令牌 (tokens) ：授权服务器在接收到客户请求后，颁发的访问令牌。
  • 作用域 (scopes) ：客户请求访问令牌时，由资源拥有者额外指定的细分权限 (permission)。

令牌类型：

  • 授权码：仅用于授权码授权类型，用于交换获取访问令牌和刷新令牌。
  • 访问令牌：用于代表一个用户或服务直接去访问受保护的资源。
  • 刷新令牌：用于去授权服务器获取一个刷新访问令牌。
  • BearerToken ：不管谁拿到 Token 都可以访问资源，类似现金。
  • Proof of Possession(PoP) Token ：可以校验 client 是否对 Token 有明确的拥有权。

优点：

  • 更安全，客户端不接触用户密码，服务器端更易集中保护
  • 广泛传播并被持续采用
  • 短寿命和封装的token
  • 资源服务器和授权服务器解耦
  • 集中式授权，简化客户端
  • HTTP/JSON友好，易于请求和传递token
  • 考虑多种客户端架构场景
  • 客户可以具有不同的信任级别

缺点：

  • 协议框架太宽泛，造成各种实现的兼容性和互操作性差。
  • 不是一个认证协议，本身并不能告诉你任何用户信息。

    1.3 认证流程

    Oauth2 - 图2
  1. 用户打开客户端以后，客户端要求用户给予授权。
  2. 用户同意给予客户端授权。
  3. 客户端使用上一步获得的授权，向认证服务器申请令牌。
  4. 认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
  5. 客户端使用令牌，向资源服务器申请获取资源。

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

    1.4 微信认证

    image.png

  7. 用户进入网站的登录页面，点击微信的图标以微信账号登录系统，用户是自己在微信里信息的资源拥有者。点击“微信”出现一个二维码，此时用户扫描二维码，开始给网站授权。

  8. 资源拥有者同意给客户端授权：资源拥有者扫描二维码表示资源拥有者同意给客户端授权，微信会对资源拥有者的身份进行验证，验证通过后，微信会询问用户是否给授权网站访问自己的微信数据，用户点击“确认登录”表示同意授权，微信认证服务器会颁发一个授权码，并重定向到网站。
  9. 客户端获取到授权码，请求认证服务器申请令牌，此过程用户看不到，客户端应用程序请求认证服务器，请求携带授权码。
  10. 认证服务器向客户端响应令牌，认证服务器验证了客户端请求的授权码，如果合法则给客户端颁发令牌，令牌是客户端访问资源的通行证。此交互过程用户看不到，当客户端拿到令牌后，用户在网站看到已经登录成功。
  11. 客户端请求资源服务器的资源：客户端携带令牌访问资源服务器的资源。网站携带令牌请求访问微信服务器获取用户的基本信息。
  12. 资源服务器返回受保护资源：资源服务器校验令牌的合法性，如果合法则向用户响应资源信息内容。

    2. 授权模式

    2.1 授权码模式

    Oauth2 - 图4

    这里引用 阮一峰 的博客： https://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html

授权码模式，指的是第三方应用先申请一个授权码，然后再拿这个授权码获取令牌。详细步骤如下：

  1. 请求授权码：A 网站提供一个链接，用户点击链接跳转到 B 网站，授权用户数据给 A 网站。（response_type 表示要求返回授权码，为授权码模式，client_id 参数让 B 知道是谁在请求，redirect_uri 表示接受或拒绝后跳转的网址，scope 表示要求的授权范围）。
  2. 返回授权码：用户跳转后，B 网站会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时 B 网站就会跳回 redirect_uri 参数指定的网址。跳转时，会传回一个授权码。
  3. 根据授权码获取令牌：A 网站拿到授权码以后，就可以在后端，向 B 网站请求令牌。认证失败服务端返回 401 Unauthorized。
  4. B 网站收到请求以后，就会颁发令牌。具体做法是向redirect_uri指定的网址，发送一段 JSON 数据。 ```java

    1、请求授权码

    https://b.com/oauth/authorize? response_type=code& client_id=CLIENT_ID& redirect_uri=a.com& scope=read

2、返回授权码

https://a.com/callback?code=AUTHORIZATION_CODE

3、根据授权码获取令牌

https://b.com/oauth/token? client_id=CLIENT_ID& client_secret=CLIENT_SECRET& grant_type=authorization_code& code=AUTHORIZATION_CODE& redirect_uri=CALLBACK_URL

4、返回令牌

{
“access_token”:”ACCESS_TOKEN”, “token_type”:”bearer”, “expires_in”:2592000, “refresh_token”:”REFRESH_TOKEN”, “scope”:”read”, “uid”:100101, “info”:{…} }

  1. <a name="jAB8z"></a>
  2. ## 2.2 简化模式
  3. ![](https://cdn.nlark.com/yuque/0/2022/png/446852/1645067244337-c49cf001-154b-40e8-9897-832ec1a2190f.png?x-oss-process=image%2Fresize%2Cw_1007%2Climit_0#crop=0&crop=0&crop=1&crop=1&from=url&height=413&id=fVc4G&margin=%5Bobject%20Object%5D&originHeight=623&originWidth=1007&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=&width=668)<br />简化模式（implicit grant type）不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。
  5. 1. 客户端将用户导向认证服务器。
  6. 1. 用户决定是否给于客户端授权。
  7. 1. 假设用户给予授权，认证服务器将用户导向客户端指定的"重定向URI"，并在 URI 的 Hash 部分包含了访问令牌。
  8. 1. 浏览器向资源服务器发出请求，其中不包括上一步收到的 Hash 值。
  9. 1. 资源服务器返回一个网页，其中包含的代码可以获取 Hash 值中的令牌。
  10. 1. 浏览器执行上一步获得的脚本，提取出令牌。
  11. 1. 浏览器将令牌发给客户端。
  12. ```java
  13. GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
  14.      &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
  15.     Host: server.example.com

2.3 密码模式

Oauth2 - 图5
密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向”服务商提供商”索要授权。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下。一般不支持 refresh token。

  1. 用户向客户端提供用户名和密码。
  2. 客户端将用户名和密码发给认证服务器，向后者请求令牌。

  3. 认证服务器确认无误后，向客户端提供访问令牌。

    2.4 客户端模式

    Oauth2 - 图6
    指客户端以自己的名义，而不是以用户的名义，向”服务提供商”进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求”服务提供商”提供服务，其实不存在授权问题。

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

  5. 认证服务器确认无误后，向客户端提供访问令牌。

    3. SpringSecurity Oauth2

    3.1 架构图

    image.png

    流程：

  6. 用户访问，此时没有 Token。Oauth2RestTemplate 会报错，这个报错信息会被 Oauth2ClientContextFilter 捕获并重定向到认证服务器。

  7. 认证服务器通过 Authorization Endpoint 进行授权，并通过 AuthorizationServerTokenServices 生成授权码并返回给客户端。
  8. 客户端拿到授权码去认证服务器通过 Token Endpoint 调用 AuthorizationServerTokenServices 生成 Token 并返回给客户端。
  9. 客户端拿到 Token 去资源服务器访问资源，一般会通过 Oauth2AuthenticationManager 调用 ResourceServerTokenServices 进行校验。校验通过可以获取资源。

    3.2 授权服务器架构

  • Authorize Endpoint ：授权端点，进行授权。
  • Token Endpoint ：令牌端点，经过授权拿到对应的 Token。
  • Introspection Endpoint ：校验端点，校验 Token 的合法性。
  • Revocation Endpoint ：撤销端点，撤销授权。

image.png