写在最前
如果这个项目让你有所收获,记得 Star 关注哦,这对我是非常不错的鼓励与支持。
源码地址(后端):https://gitee.com/csps/mingyue-springcloud-learning
源码地址(前端):https://gitee.com/csps/mingyue-springcloud-ui
文档地址:https://gitee.com/csps/mingyue-springcloud-learning/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,代表应用自身的资源授权