JeecgBoot 应用 Spring Authorization Server
> 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 在认证安全领域得到了补齐，更加深层次的保障了普通用户对访问安全功能的需要。
页:
[1]