高效管理用户权限：深入探索Spring Security的多用户类型认证、授权和Token刷新

news2025/2/22 12:17:46

前言

对于spring secutiry 来讲，其默认是只支持一种数据类型进行认证的，因为最后组件的方法仅为：loadUserByUsername(String username) 方法。

如果有多个系统来使用这个认证模块，会导致查询问题。这也就是不支持多用户类型认证的原因。

因为是多个系统，所以不同系统需要到自己的系统或者表中查询自己的数据，而单单一个参数username显然是不能满足需求的，这里至少还需一个参数来区别不同系统才行。

尽管对于不同系统可以通过增加自定义类型的方法来清醒请求access_token，即调用接口

oauth/token 来获取认证信息。

即如下：

但是，在使用刷新token接口的时候，根据spring security 的机制和上面所说，还是会调用默认的loadUserByUsername 方法，导致程序报错。

这里就需要从程序的角度进行修改。这就是这里介绍的多用户数据类型的情况。

即都是刷新接口，都是调用/oauth/token接口，对应grant_type类型都是password_code类型，

对应在接口中增加一个userType即可。

刚才讲到，自定义授权类型的情况，对于兼容其他系统认证的情况，个人感觉还是不合适的，也就是为了兼容其他系统登录认证最合适的做法是稍后下面的做法，而不是增加授权类型这种这种的方式。

因为，即使获取access_token通过增加授权类型解决了，同样，刷新token还是需要更改，而2者内部其实是使用的同一套东西。

整个过程核心机制是通过接口中增加一个参数如userType来进行识别不同的系统类型，

后台逻辑中通过这个类型而进行判断。

1 登陆获取token

1.1 新增ZltUserDetailsService extends UserDetailsService，

新增自定义的方法。

因直接使用项目中内容，类方法就没有改，自定义适配的可以叫做：

CustomUserDetailsService

具体的实现逻辑，后续即可根据userType的值进行不同的执行逻辑：

需要注意：这里的userType 是接口传过来的。

后面的所有需要用到userDetailsService的，全部都要替换成自定义ZltUserDetailsService

1.2 复制org.springframework.security.authentication.dao.DaoAuthenticationProvider的代码，自定义 CustomAuthenticationProvider(注意写法，是实现AbstractUserDetailsAuthenticationProvider并将DaoAuthenticationProvider内容复制到此类里面)，然后进行修改retrieveUser()方法，其他不需要动.

如下：

1.修改 retrieveUser 方法：

可以根据实际逻辑进行编码即可，这里是调用上面逻辑中自定义方法的逻辑：

2.修改成员变量：

将 UserDetailsService 变量替换成 ZltUserDetailsService

同理修改相关的get和set方法：

1.3 到WebSecurityConfigurerAdapter上配置CustomAuthenticationProvider内容。

在目前系统中是 SecurityConfig 类继承了CustomAuthenticationProvider类，故在此类中配置

需注释掉原来的内容：全局用户信息部分。

同步修改成员变量：

配置完成后，可以请求接口进行

对应请求参数中增加userType即可。

2 刷新Token

对应逻辑需要同步修改，否则刷新token逻辑会调用原始loadUserByUsername

2.1 复制org.springframework.security.core.userdetails.UserDetailsByNameServiceWrapper 自定义 CustomUserDetailsByNameServiceWrapper 在 loadUserDetails() 方法添加自定义的userType

这里依然是复制整个内容，并不是继承UserDetailsByNameServiceWrapper