基于Spring Security 6的OAuth2 系列之一 - 开篇入门

linmoo1986

已于 2025-01-23 13:31:53 修改

阅读量1.2k

点赞数 10

分类专栏： OAuth2 文章标签： oauth2 springsecurity6 授权码模式密码模式简化模式客户端模式

于 2025-01-21 10:35:42 首次发布

本文链接：https://blog.youkuaiyun.com/linwu_2006_2006/article/details/144627521

版权

OAuth2 专栏收录该内容

25 篇文章

订阅专栏

之所以想写这一系列，是因为之前工作过程中使用Spring Security OAuth2搭建了网关和授权服务器，但当时基于spring-boot 2.3.x，其默认的Spring Security是5.3.x。之后新项目升级到了spring-boot 3.3.0，结果一看Spring Security也升级为6.3.0。无论是Spring Security的风格和以及OAuth2都做了较大改动，里面甚至将授权服务器模块都移除了，导致在配置同样功能时，花费了些时间研究新版本的底层原理，这里将一些学习经验分享给大家。

注意：由于框架不同版本改造会有些使用的不同，因此本次系列中使用基本框架是 spring-boo-3.3.0（默认引入的Spring Security是6.3.0），JDK版本使用的是19，本系列OAuth2的代码采用Spring Security6.3.0框架，所有代码都在oauth2-study项目上：https://github.com/forever1986/oauth2-study.git

1 OAuth2.0是什么

有2.0就有1.0，目前还出了2.1，这个我们先不细讲。我们先从官方文档RFC 6749中，看看怎么描述OAuth2.0的，了解一下OAuth2.0是做什么的。下面是从官方文档摘出来的一段话：

The OAuth 2.0 Authorization Framework
Abstract
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.

直接使用翻译软件：

OAuth 2.0授权框架允许第三方应用程序获取对HTTP服务的有限访问权限，通过编排审批交互来代表资源所有者在资源所有者和HTTP服务之间，或者通过允许第三方应用程序以自己的名义获得访问权限。这规范取代并废弃了所描述的OAuth 1.0协议在RFC 5849。

我们关注几个关键词：第三方应用程序、有限访问、资源所有者
从上面的关键词，我们大概能猜出OAuth 2.0是一个授权的东西，其中还包括了第三方应用程序、资源所有者等角色。简单来说OAuth 2.0是一个授权协议框架（也就是一个空壳子），规范了资源所有者（也就是你）允许授权给第三方应用程序，授权后，第三方应用程序可以从资源所有者中有限访问资源的流程。这么说还是有点模糊，我们举一个实际应用例子来说明一下，这样你可能更有感觉：

假如你是一个淘宝商家，然后你想通过你的订单数据分析你的客户，这时候你请了一个第三方分析应用。你每个月就从淘宝导出数据，再导入到第三方分析应用中。这样过程你觉得很麻烦。
有一个办法就是把你的淘宝账号密码交给第三方分析应用系统，然后它用你的账号密码开发接口拉取数据。这样虽然方便了，但是有一个安全隐患，就是第三方分析应用知道你的淘宝账号密码。
那么，有没有一种办法在第三方分析应用不知道我的淘宝账号密码的情况下能拉取订单数据？这时候OAuth协议就诞生了，它就规范了在不获取你淘宝账号密码的情况下，又能够获取到你的订单数据，而其它数据它无法获取。而且它获取数据还需要你先同意，你还可以控制给它的权限的有效期。

1.1 关键角色

通过前面的例子，是不是比较能够理解一些，其中分了好几个角色。那么接下来我们结合例子来说明一下OAuth 2.0的一些关键角色：

客户端（Client）：请求访问资源的第三方应用；上面的例子就是第三方分析应用
授权服务器（Authorization Server）：授权服务器是用于处理和发放访问令牌的服务器。当用户请求访问资源时，需要先向授权服务器请求访问令牌。上面的例子就是淘宝。
资源服务器（Resource Server）：资源服务器是用于存储和管理资源的服务器；当用户拥有访问令牌后，就可以向资源服务器请求访问资源。上面的例子就是淘宝的订单数据，第三方分析应用从淘宝上面获得订单数据。（注意：我们看到的例子授权服务器和资源服务器都是淘宝，实际情况授权服务器和资源服务器可以分开的）
资源所有者（Resource Owner）：资源所有者通常就是指用户。上面的例子就是你。
访问令牌（Access Token）：访问令牌是授权服务器发放给客户端的一个凭证，表示客户端有权访问资源所有者的资源。访问令牌有一定的有效期，过期后需要使用刷新令牌来获取新的访问令牌。上面的例子虽然没有提到，但是结果可能是给了一个临时凭证，让第三方分析应用可以获取到订单数据，而这个凭证就是访问令牌。
刷新令牌（Refresh Token）：刷新令牌是授权服务器在发放访问令牌时一同发放的一个凭证，用于在访问令牌过期后获取新的访问令牌。刷新令牌通常有较长的有效期，甚至可以设置为永不过期。上面例子说你可以控制它的权限有效期，就是通过令牌有效期控制。

1.2 基本流程

基本了解完关键角色之后，我们将官方的图结合上面的例子，给你展现一下OAuth 2.0的基本流程
在这里插入图片描述

A：Client（第三方分析应用）去请求获得Resource Owner（你）的淘宝订单数据的授权
B：Resource Owner（你）授权给Client（第三方分析应用）
C：Client（第三方分析应用）去Authorization Server（淘宝）获得授权令牌
D：Authorization Server（淘宝）给Client（第三方分析应用）发放授权令牌
E：Client（第三方分析应用）拿着授权令牌，去Resource Server（淘宝订单）获取数据
F：Resource Server（淘宝订单）验证令牌有效后，提供订单数据给Client（第三方分析应用）

2 OAuth2的模式

我们从上面了解到OAuth2的基本流程（如上图所示），但是其获得授权的方式却有不同的模式也就意味着在A到D这四步会有不同的方式，了解OAuth2的模式的是必需的，因为无论你是搭建客户端或者授权服务器，都必须知道你要采用的是哪种模式。下面讲解一下OAuth2的模式。（我会结合上面举得淘宝例子放到官方图中做解释）

2.1 授权码模式(Authorization Code Grant)

授权码模式：是 OAuth2.0 中最常用的一种模式，这种模式适合那些可以安全存储客户端凭证的应用程序（如 Web 服务器应用），并且它将客户端与资源所有者分离，增加了安全性。授权码是里面流程最复杂，但却是最安全的，大部分开放的OAuth2授权模式都是这种方式。下图为官方授权码模式下的流程。
在这里插入图片描述

A：你（User-Agent）打开第三方分析应用（Client客户端），会跳转到**淘宝（Authorization Server授权服务器）**的授权界面
B：**你（User-Agent）**点击确认授权
C：**淘宝（Authorization Server授权服务器）**会返回一个授权码Code（注意：该Code并非令牌，而是一个临时授权码Code，为了后面能获得令牌），**第三方分析应用（Client客户端）**得到这个授权码Code。
D：第三方分析应用（Client客户端）使用授权码Code，再次访问淘宝（Authorization Server授权服务器）去获得令牌token
E：淘宝（Authorization Server授权服务器）验证授权码code无误后，返回令牌token。

2.2 客户端模式(Client Credentials Grant)

客户端模式：是指客户端（第三方分析应用）以自身身份而不是用户身份向授权服务器请求访问令牌，即没有用户直接参与的授权流程。这种认证对于用户来说是不安全的，因为获得授权并不需要得到用户的确认，因此一般只用于内部系统之间（因为内部系统属于完全可信任的客户端）。如下图，其流程很简单：

在这里插入图片描述

A：**第三方分析应用（Client客户端）直接请求淘宝（Authorization Server授权服务器）**的授权（当然会发客户端凭证给授权服务器）
B：淘宝（Authorization Server授权服务器）验证通过，直接发放令牌token给第三方分析应用（Client客户端）

2.3 密码模式(Resource Owner Password Credentials Grant)（将弃用）

注意：该模型在OAuth2.1已经弃用，后续也不会有代码实现，但是你可以了解一下流程

密码模式：指定是客户端使用用户的凭证（也就是账号密码）向授权服务器申请令牌。这个会暴露用户的用户名和密码，并没有解决我们说的淘宝例子的问题，这种模式在 OAuth2 中安全性较低，因为用户的凭证直接暴露给客户端，因此将在OAuth2.1弃用。

在这里插入图片描述

A：你（Resource Owner）将自己的凭证（账号密码）提供给第三方分析应用（Client客户端）
B：第三方分析应用（Client客户端）通过凭证去淘宝（Authorization Server授权服务器）获取令牌token
C：淘宝（Authorization Server授权服务器）验证通过后，发放令牌token

2.4 简化模式(Implicit Grant)（将弃用）

注意：该模型在OAuth2.1已经弃用，后续也不会有代码实现，但是你可以了解一下流程

简化模式：其实就是简化了授权码模式，授权码模式中需要先获得授权码code，再获得令牌token，而简化模式直接获得令牌token。由于访问令牌token暴露在 URL 中，容易被中间人攻击（例如通过 URL 拦截），不安全，因此OAuth2.1已经弃用。

在这里插入图片描述

A：你（User-Agent）打开第三方分析应用（Client客户端），会跳转到**淘宝（Authorization Server授权服务器）**的授权界面
B：**你（User-Agent）**点击确认授权
C：淘宝（Authorization Server授权服务器）确认授权后，返回Hash值，其中就会包含令牌token
D：使用浏览器自动取访问淘宝订单（Resource Server资源服务器）
E：**淘宝订单（Resource Server资源服务器）**会返回一个script脚本（该脚本是用来解析Hash值）。
F：浏览器使用E中获取到的Script去解析C中获取到的Hash值，从中获得令牌token
E：浏览器将解析到的令牌token发给第三方分析应用（Client客户端）

结语：这一章我们基本上对OAuth2做什么的做了基本了解，同时还了解了其关键角色以及模式，这两部分都是非常重要的，因为后面编程都需要理清楚你是什么角色，以及采用哪种模式。我们接下来会通过客户端、授权服务器以及资源服务器三个方面讲述整个Spring Security实现OAuth的过程。下面3章主要是从一个Client客户端角色，使用授权码模式，让github给我们授权并访问github获得用户信息，并讲解Spring Security的oauth2-client组件底层原理。