OAuth2详解 · 浮光笔记

介绍

前言

传统的客户端-服务器身份验证模型中存在的问题。在这种模型中，客户端通过使用资源所有者的凭据对服务器进行身份验证，从而请求访问受限资源（受保护的资源）。为了使第三方应用程序能够访问受限资源，资源所有者需与第三方共享其凭据。然而，这种做法存在一些问题和限制：

第三方应用程序通常需要明文存储资源所有者的凭据（通常是密码），以备将来使用。
服务器需要支持密码身份验证，而且密码身份验证存在安全弱点。
第三方应用程序可能获得对资源所有者受保护资源的过于广泛的访问权限，而资源所有者无法限制对资源的访问时长或访问的资源子集。
资源所有者无法单独撤销对个别第三方的访问权限，而不影响所有第三方的访问权限，只能通过更改第三方的密码来执行此操作。
如果任何第三方应用程序遭到破坏，将导致最终用户密码以及由该密码保护的所有数据的泄露。

什么是OAuth 2.0

OAuth 2.0（开放授权2.0）是一种用于授权的开放标准，允许用户让第三方应用访问他们在某一网站上存储的私有资源，而无需将用户名和密码提供给第三方应用。OAuth 2.0是OAuth协议的升级版本，提供了更简化和灵活的授权流程。

在OAuth 2.0中，授权过程包括以下主要角色：

资源所有者（Resource Owner）：即用户，是拥有受保护资源的实体。用户通过授权第三方应用访问他们的资源。
客户端（Client）：即第三方应用，需要访问资源所有者的受保护资源。
授权服务器（Authorization Server）：负责验证资源所有者并颁发访问令牌给客户端。授权服务器和资源服务器可以是同一个服务或不同的服务。
资源服务器（Resource Server）：存储受保护资源的服务器，通过访问令牌验证并提供受保护资源。

在OAuth 2.0中，定义了多种授权方式（授权码模式、隐式授权模式、密码模式、客户端凭证模式等），客户端通过与授权服务器交互，获取访问令牌，然后使用访问令牌访问受保护资源。

应用场景

假如你正在“网站A”上冲浪，看到一篇帖子表示非常喜欢，当你情不自禁的想要点赞时，它会提示你进行登录操作。打开登录页面你会发现，除了最简单的账户密码登录外，还为我们提供了微博、微信、QQ等快捷登录方式。假设选择了快捷登录，它会提示我们扫码或者输入账号密码进行登录。登录成功之后便会将QQ/微信的昵称和头像等信息回填到“网站A”中，此时你就可以进行点赞操作了。

名词定义

在详细讲解oauth2之前，先来了解一下它里边用到的名词定义吧：

Client：客户端，它本身不会存储用户快捷登录的账号和密码，只是通过资源拥有者的授权去请求资源服务器的资源，即例子中的网站A；
Resource Owner：资源拥有者，通常是用户，即例子中拥有QQ/微信账号的用户；
Authorization Server：认证服务器，可以提供身份认证和用户授权的服务器，即给客户端颁发token和校验token；
Resource Server：资源服务器，存储用户资源的服务器，即例子中的QQ/微信存储的用户信息；

认证流程

如图是oauth2官网的认证流程图，我们来分析一下：

A 客户端向资源拥有者发送授权申请；
B 资源拥有者同意客户端的授权，返回授权码；
C 客户端使用授权码向认证服务器申请令牌token；
D 认证服务器对客户端进行身份校验，认证通过后发放令牌；
E 客户端拿着认证服务器颁发的令牌去资源服务器请求资源；
F 资源服务器校验令牌的有效性，返回给客户端资源信息；

流程如下图：图片

实战

在正式开始搭建项目之前我们先来做一些准备工作：要想使用oauth2的服务，得先创建几张表。

数据库

oauth2相关的建表语句可以参考官方初始化sql，也可以查看项目中的init.sql文件

表结构，字段的含义如下：

oauth_client_details：存储客户端的配置信息，操作该表的类主要是JdbcClientDetailsService.java；
oauth_access_token：存储生成的令牌信息，操作该表的类主要是JdbcTokenStore.java；
oauth_client_token：在客户端系统中存储从服务端获取的令牌数据，操作该表的类主要是JdbcClientDetailsService.java；
oauth_code：存储授权码信息与认证信息，即只有grant_type为authorization_code时，该表才会有数据，操作该表的类主要是JdbcAuthorizationCodeServices.java；
oauth_approvals：存储用户的授权信息；
oauth_refresh_token：存储刷新令牌的refresh_token，如果客户端的grant_type不支持refresh_token，那么不会用到这张表，操作该表的类主要是JdbcTokenStore；

在oauth_client_details表中添加一条数据

资源服务

模拟资源访问

接着创建配置类继承ResourceServerConfigurerAdapter并增加@EnableResourceServer注解开启资源服务，重写两个configure方法

当然我们也可以配置忽略校验的url，在上边的public void configure(HttpSecurity http) throws Exception中进行配置

然后将实现了UserDetails的SysUser和实现了GrantedAuthority的SysRole放到项目中，当请求发过来时，oauth2会帮我们自行校验。

认证服务

配置文件对服务端口、应用名称、数据库、mybatis和日志进行了配置。

Security配置

①将继承了UserDetailsService的ISysUserService的实现类SysUserServiceImpl重写loadUserByUsername方法

②继承WebSecurityConfigurerAdapter类，增加@EnableWebSecurity注解并重写方法

AuthorizationServer配置

①继承AuthorizationServerConfigurerAdapter类，增加@EnableAuthorizationServer注解开启认证服务

②依赖注入，注入7个实例Bean对象

③重写方法进行配置

模式

授权码模式

原理

前边所讲的内容都是基于授权码模式，授权码模式被称为最安全的一种模式，它获取令牌的操作是在两个服务端进行的，极大的减小了令牌泄漏的风险。

客户端请求授权：用户访问客户端，客户端将用户导向授权服务器，并包含以下参数：

response_type=code：表示使用授权码模式。
client_id：标识客户端。
redirect_uri：授权成功后重定向的URI。
scope：请求的权限范围。

用户同意授权：用户在授权服务器登录并同意授权请求。

授权服务器发放授权码：授权服务器验证用户身份和授权请求后，向客户端发放授权码。

客户端获取访问令牌：客户端通过后端将授权码和客户端凭证发送到授权服务器。包含以下参数：

grant_type=authorization_code：表示使用授权码模式。
code：授权码。
redirect_uri：必须与步骤1中的重定向URI一致。
client_id：客户端标识。
client_secret：客户端秘钥（可选）。

授权服务器发放访问令牌：授权服务器验证授权码和客户端凭证，如果有效则发放访问令牌。

客户端使用访问令牌：客户端可以使用访问令牌访问用户的受保护资源。

授权码模式相对于其他模式更安全，因为客户端不直接接触用户凭证，且在授权码的交换过程中可以使用安全的后端通信。

案例

启动两个服务，当再次请求127.0.0.1:9002/product/findAll接口时会提示以下错误

①调用接口获取授权码

发送127.0.0.1:9001/oauth/authorize?response_type=code&client_id=cheetah_one请求，前边的路径是固定形式的，response_type=code表示获取授权码，client_id=cheetah_one表示客户端的名称是我们数据库配置的数据。该页面是oauth2的默认页面，输入用户的账户密码点击登录会提示我们进行授权，这是数据库oauth_client_details表我们设置autoapprove为false起到的效果。选择Approve点击Authorize按钮，会发现我们设置的回调地址（oauth_client_details表中的web_server_redirect_uri）后边拼接了code值，该值就是授权码。查看数据库发现oauth_approvals和oauth_code表已经存入数据了。

拿着授权码去获取token 获取到token之后oauth_access_token和oauth_refresh_token表中会存入数据以用于后边的认证。而oauth_code表中的数据被清除了，这是因为code值是直接暴漏在网页链接上的，oauth2为了防止他人拿到code非法请求而特意设置为仅用一次。