Spring Authorizaiton Server, 简称 sas，是一个授权服务器框架，提供 OAuth2.1 与 Open Connect 1.0 认证规范及其他规范的实现，它建立在 Spring Security 之上，为构建 OpenID Connect 1.0 Identity Provider 和 OAuth2 授权服务器产品提供了一个安全、轻量级和可定制的基础。

升级必要性

Spring Authorization Server 项目是 Spring 团队对原有的 Spring Security Oauth 模块的升级，同时对 Oauth 协议的实现由 2.0 升级到最新的 2.1 版本，并且现在已经停止了对该模块的维护。另外 Spring 团队基于 Spring Security Oauth 的经验，对大量代码进行了简化，使认证运行效率变得更高，可介入性以及可兼容性比起以前变得更加优秀。

OAuth 2.1 基于 Oauth2 的基础上进行更新，考虑到安全性的问题，移除了 OAuth2 的简化模式、密码模式。由于现在越来越多的硬件设备具备智能化功能，对设备认证也逐渐有了要求，OAuth2.1 本次新增了设备码认证模式，针对于无浏览器类设备进行登录使用。

JeecgBoot 登录认证

JeecgBoot 目前有四种登录情况：

1. PC 端用户名密码登录（APP 登录）
2. 手机号登录
3. 三方社交平台登录（Github、钉钉、微信、企业微信）
4. CAS 登录

目前这四种登录情况的核心都是使用的自建 JWT token，使用 shiro 框架完成的登录验证及请求授权验证，由 JeecgBoot 本身完全请求用户的密码验证、验证码验证等等，两个部分可以看作是完全分离的。如同冰箱的功能是冷藏 + 冷冻，而我们需要保证放进冰箱的食品有效期。

JeecgBoot 如何切换

在前文我们讲到 JeecgBoot 的用户验证与授权验证是分离式的，所以我们本次切换的注意力只需要放在替换现在的 shiro，使用 Spring Authorization Server 进行登录验证及请求授权验证。

Spring Authoriztion Server 默认支持授权码模式、客户端模式、设备码模式及刷新码模式，并且提供了对应的接口，同时也支持自定义扩展。我们可以对 AuthenticationProvider 接口进行实现，具体实现逻辑可根据自身需求而定，最终只需要返回一个 OAuth2AccessTokenAuthenticationToken 对象即可。JeecgBoot 本次参考了 Shiro 原有的逻辑进行实现，只不过本次调整了手动生成 Token 转成由 Spring Authorization Server 生成 Token，同时使用 Spring Authorization Server 对 redis 的集成，对生成的认证信息保存至 redis 中，JeecgBoot 刚好可以利用这点，完成对在线用户强制退出功能的继承。

切换之前的逻辑路线为：

1. 用户请求登录
2. JeecgBoot 完成用户密码、验证码等认证
3. 使用用户名密码手动生成 JWT token
4. 用户携带 token 进行请求时，由 shiro 对 token 进行拦截获取其中的用户名，对用户进行 token 校验及权限校验

切换之后的逻辑路线为：

1. 用户请求登录
2. JeecgBoot 完成用户密码、验证码等认证。
3. 使用用户名访问基于 Spring Authorization Server 扩展的认证模式进行 token 生成，并保存至 redis 中。
4. 用户携带 token 进行请求时，Spring Authorization Server 对 token 进行拦截获取其中的用户名，对用户进行 token 校验及权限校验。

JeecgBoot 切换的原因

Jeecg 考虑到 JeecgBoot 的用户群体越来越庞大，甚至部分用户对编码几乎都不了解，JeecgBoot 需要降低使用的便利性、安全性、扩展性。而 Shiro 相对来说，功能太过单薄，扩展性不足，无法与 JeecgBoot 本身融为一体。本次 Spring Authorization Server 的加入，可以使认证逻辑与 JeecgBoot 融为一体，并且自动满足了对通用性认证、跨平台性、多平台性认证协议完成了集成，让 JeecgBoot 在认证安全领域得到了补齐，更加深层次的保障了普通用户对访问安全功能的需要。