Sa-Token控制框架

一、核心原理对比项目JWTSa-Token认证方式无状态认证Token Session服务器是否存储❌ 不存✅ 存Token 内容包含用户信息只是一个ID校验方式解密签名查 session扩展方式微服务友好单体或网关更好JWT 工作方式JWT 是一种自包含 Token。结构header.payload.signature例如eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...流程用户登录 ↓ 服务器生成 JWT ↓ 返回给客户端 ↓ 客户端每次请求带 JWT ↓ 服务器解析 JWT服务器只需要验证签名不需要存储 session。Sa-Token 工作方式Sa-Token 是token session store流程用户登录 ↓ 生成 token ↓ 服务器保存 token → userId ↓ 客户端带 token ↓ 服务器查 session例如token: 3e9c1c2f服务器3e9c1c2f → userId:1001二、架构区别JWT 架构Client │ │ JWT ▼ API Server │ │ verify signature ▼ User特点无状态不需要 Redis不需要 sessionSa-Token 架构Client │ │ token ▼ API Server │ │ 查 session ▼ Redis / Memory │ ▼ User特点有状态需要 Redissession 管理强三、功能能力对比功能JWTSa-Token踢人下线❌ 很难✅ 很容易并发登录控制❌ 困难✅ 内置权限系统❌ 自己写✅ 内置单点登录❌ 复杂✅ 支持黑名单❌ 复杂✅ 支持四、优缺点对比JWT 优点1 无状态服务器不用存 session。适合高并发 微服务 分布式2 微服务友好多个服务都可以解析 JWTService A Service B Service C不需要共享 Redis。3 扩展性好JWT 可以跨系统APP WEB 第三方 APIJWT 缺点1 无法立即失效JWT 一旦发出token 未过期 一直有效想踢用户下线很麻烦。2 Token 可能很大JWT 可能包含{userId:1,role:admin,permissions:[]}请求头会变大。3 权限变更难如果用户权限变了JWT 还是旧权限必须重新登录。五、Sa-Token 优点1 登录控制强可以做到StpUtil.kickout(userId);立即下线。2 权限控制方便例如SaCheckPermission(admin)3 多端登录例如WEB APP ADMIN都能管理。4 Session 可以存数据例如StpUtil.getSession().set(user,user);类似session.setAttribute()六、Sa-Token 缺点1 必须有存储需要Redis Memory否则无法扩展。2 微服务复杂多个服务要共享session store3 每次请求都要查存储比 JWT 多一次 IO。七、真实项目怎么选这是最重要的。单体系统推荐Sa-Token例如后台管理系统企业系统内部系统原因权限控制方便 踢人下线简单 开发效率高微服务系统推荐JWT例如API 网关分布式系统SaaS 平台原因无状态 服务之间认证简单 扩展性好API 平台推荐JWT因为第三方调用 跨服务 跨系统需要强登录控制推荐Sa-Token例如金融系统 管理后台 运营平台八、你的项目适合哪个你前面说的项目是人格测试 API 产品如果是开放 API建议JWT原因无状态 可扩展 适合 API如果是后台管理系统建议Sa-Token原因权限控制方便 开发简单九、一句话总结可以记住这个简单规则单体系统 → Sa-Token 微服务 / API → JWT