写在最前

如果这个项目让你有所收成，记住 Star 重视哦，这对我是十分不错的鼓舞与支撑。

源码地址：gitee.com/csps/mingyu…

文档地址：gitee.com/csps/mingyu…

技术选型

本微服务将选用 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
  • Sa-Token：一个轻量级 Java 权限认证结构，有中文文档，也迭代到了3.4.0，现在还算稳定，引荐！✔

Sa-Token

当你看完 Spring Security、Spring Authorization Server 文档，再看 Sa-Token 文档，就会有一种真 TM 简单的感觉。

最新开发文档永远在：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规划了四种形式

  1. 授权码（Authorization Code）：OAuth2.0 标准授权过程，Server 端向 Client 端下放 Code 码，Client 端再用 Code码交换授权 Token

    001-从零搭建微服务-认证中心（一）

  2. 隐藏式（Implicit）：无法运用授权码形式时的备用挑选，Server 端运用 URL 重定向方式直接将 Token 下放到 Client端页面

  3. 暗码式（Password）：Client 直接拿着用户的账号暗码交换授权 Token

    001-从零搭建微服务-认证中心（一）

  4. 客户端凭证（Client Credentials）：Server 端针对 Client 等级的 Token，代表使用自身的资源授权