写在最前
如果这个项目让你有所收获，记得 Star 关注哦，这对我是非常不错的鼓励与支持。
源码地址：https://gitee.com/csps/mingyue
文档地址：https://gitee.com/csps/mingyue/wikis
技术选型
本微服务将采用
Sa-Token作为权限认证框架！
- Apache Shiro：相对来说比较老了，授权第三方登录需要手动实现，实现 oauth 比较麻烦。 不推荐！✘
- Spring Security： 非常完善了，网上也有很多的实现案例，但 Spring Security 团队正式宣布 Spring Security OAuth 终止维护（该项目将不会再进行任何的迭代，包括 Bug 修复）。 新项目不是很推荐！✘
- 作为 SpringBoot 3.0 的过渡版本 SpringBoot 2.7.0 过期了大量关于 SpringSecurity 的配置类,如沿用旧版本过期配置无法向上升级。
- Spring Authorization Server：目前 Spring 生态中的 OAuth2 授权服务器主推的项目，应该会是未来 Spring 家族很长一段时间的 OAuth2 解决方案。推荐！✔
- 缺点也是有的，截至目前为止才得迭代到 1.1.0，目前案例与文档也比较少，推荐一个开源项目 pig，他目前采用的就是
Spring Authorization Server 0.4.0作为 OAuth2 认证服务。 - 推荐阅读文章：【安全篇】Spring Boot 整合 Spring Authorization Server
- 缺点也是有的，截至目前为止才得迭代到 1.1.0，目前案例与文档也比较少，推荐一个开源项目 pig，他目前采用的就是
- Sa-Token：一个轻量级 Java 权限认证框架，有中文文档，也迭代到了3.4.0，目前还算稳定，推荐！✔
Sa-Token
当你看完 Spring Security、Spring Authorization Server 文档，再看 Sa-Token 文档，就会有一种真 TM 简单的感觉。
最新开发文档永远在：https://sa-token.cc
Sa-Token 文档尽力讲解每个功能的设计原因、应用场景，用心阅读文档，确实学习到的将不止是 Sa-Token 框架本身，更是绝大多数场景下权限设计的最佳实践。
目前功能一览
- 登录认证 —— 单端登录、多端登录、同端互斥登录、七天内免登录
- 权限认证 —— 权限认证、角色认证、会话二级认证
- Session会话 —— 全端共享Session、单端独享Session、自定义Session
- 踢人下线 —— 根据账号id踢人下线、根据Token值踢人下线
- 账号封禁 —— 登录封禁、按照业务分类封禁、按照处罚阶梯封禁
- 持久层扩展 —— 可集成Redis、Memcached等专业缓存中间件，重启数据不丢失
- 分布式会话 —— 提供jwt集成、共享数据中心两种分布式会话方案
- 微服务网关鉴权 —— 适配Gateway、ShenYu、Zuul等常见网关的路由拦截认证
- 单点登录 —— 内置三种单点登录模式：无论是否跨域、是否共享Redis，都可以搞定
- OAuth2.0认证 —— 轻松搭建 OAuth2.0 服务，支持openid模式
- 二级认证 —— 在已登录的基础上再次认证，保证安全性
- Basic认证 —— 一行代码接入 Http Basic 认证
- 独立Redis —— 将权限缓存与业务缓存分离
- 临时Token认证 —— 解决短时间的Token授权问题
- 模拟他人账号 —— 实时操作任意用户状态数据
- 临时身份切换 —— 将会话身份临时切换为其它账号
- 前后端分离 —— APP、小程序等不支持Cookie的终端
- 同端互斥登录 —— 像QQ一样手机电脑同时在线，但是两个手机上互斥登录
- 多账号认证体系 —— 比如一个商城项目的user表和admin表分开鉴权
- Token风格定制 —— 内置六种Token风格，还可：自定义Token生成策略、自定义Token前缀
- 注解式鉴权 —— 优雅的将鉴权与业务代码分离
- 路由拦截式鉴权 —— 根据路由拦截鉴权，可适配restful模式
- 自动续签 —— 提供两种Token过期策略，灵活搭配使用，还可自动续签
- 会话治理 —— 提供方便灵活的会话查询接口
- 记住我模式 —— 适配[记住我]模式，重启浏览器免验证
- 密码加密 —— 提供密码加密模块，可快速MD5、SHA1、SHA256、AES、RSA加密
- 全局侦听器 —— 在用户登陆、注销、被踢下线等关键性操作时进行一些AOP操作
- 开箱即用 —— 提供SpringMVC、WebFlux等常见web框架starter集成包，真正的开箱即用
单点登录与 OAuth2.0
本微服务将采用
OAuth2.0作为权限认证解决方案！
| 功能点 | SSO单点登录 | OAuth2.0 |
|---|---|---|
| 统一认证 | 支持度高 | 支持度高 |
| 统一注销 | 支持度高 | 支持度低 |
| 多个系统会话一致性 | 强一致 | 弱一致 |
| 第三方应用授权管理 | 不支持 | 支持度高 |
| 自有系统授权管理 | 支持度高 | 支持度低 |
| Client级的权限校验 | 不支持 | 支持度高 |
| 集成简易度 | 比较简单 | 难度中等 |
单点登录
举个场景，假设我们的系统被切割为 N 个部分：游戏、论坛、直播、社交…… 如果用户每访问一个模块都要登录一次，那么用户将会疯掉， 为了优化用户体验，我们急需一套机制将这 N 个系统的认证授权互通共享，让用户在一个系统登录之后，便可以畅通无阻的访问其它所有系统。
单点登录——就是为了解决这个问题而生！
简而言之，单点登录可以做到：在多个互相信任的系统中，用户只需登录一次，就可以访问所有系统。
OAuth2.0
简单来讲，OAuth2.0 的应用场景可以理解为单点登录的升级版，单点登录解决了多个系统间会话的共享，OAuth2.0 在此基础上增加了应用之间的权限控制。OAuth2.0 可以是通往 SSO 这个 “罗马” 的其中一条路，但它们本身并列于不同的场景与需求。
基于不同的使用场景，OAuth2.0设计了四种模式
-
授权码（Authorization Code）：OAuth2.0 标准授权步骤，Server 端向 Client 端下放 Code 码，Client 端再用 Code码换取授权 Token
-
隐藏式（Implicit）：无法使用授权码模式时的备用选择，Server 端使用 URL 重定向方式直接将 Token 下放到 Client端页面
-
密码式（Password）：Client 直接拿着用户的账号密码换取授权 Token
-
客户端凭证（Client Credentials）：Server 端针对 Client 级别的 Token，代表应用自身的资源授权
