大家好,又见面了,我是你们的朋友全栈君。
看过不少JWT和单点登录系统的文章,这里就根据自己的实际开发经验谈一下我的理解。大致可以总结为以下三种方案:
三种方案:
1. 纯Jwt
2. Jwt + 认证中心Redis
3. Jwt + 认证中心Redis + 多系统Redis
1. 纯Jwt 方案
1. 用户去认证中心登录,认证中心生成jwt,返回给客户端。
2. 客户端携带jwt请求多个系统
3. 每个系统各自解析jwt,取出用户信息。能解析成功就说明jwt有效,继续处理自己的业务逻辑。
(所有系统的jwt密钥保持一致才能各自解析成功)
优点:认证流程简单,服务端处理速度快。
缺点:因为简单,所以不安全。jwt一旦下发,有效期内就无法使其主动失效。
一句话总结:认证中心创建Jwt,其他系统解析。
2.Jwt + 认证中心Redis
1. 用户去认证中心登录,认证中心生成jwt,保存到redis并返回给客户端。
2. 客户端携带jwt去多个系统认证
3. 每个系统只负责从请求中取出jwt, 传给认证中心。认证解析用户信息,
并与redis中的jwt校验,判断是否有效。然后返回用户信息给刚才发起验证请求的系统。
优点:安全性高,服务端能控制jwt主动失效。
缺点:每次请求需要认证的接口,都需要访问认证中心,耗时略长。
一句话终结:认证中心负责Jwt的创建与解析,其他系统不参与认证逻辑。
3.Jwt + 认证中心redis + 多系统redis
1.用户去认证中心登录,认证中心生成jwt,保存到redis并返回给客户端。
2.客户端携带jwt去多个系统认证
3.多系统(比如系统A)收到jwt,A解析并取出用户信息,先判断自己的A的redis中有没有jwt。
3.1 如果有,就合法,a系统可以继续执行业务逻辑。
3.2 如果没有就拿着jwt去认证中心验证。
3.2.1 如果通过,a系统就把这个jwt保存到自己的redis,并设置对应的失效时间。
下次这个jwt再来到a的时候,就不需要去认证中心校验了。
3.2.2 如果验证不通过此次请求就不合法,告诉客户端需要跳转登录页面,
去认证中心登录,返回步骤1。
优点:安全性高,平均认证过程较快。
缺点:服务端流程复杂,需要考虑jwt的同步问题。比如注销或重新登录后,认证中心删除
旧jwt需要同步给其他系统,其他系统删除自己保存的jwt。
一句话总结:认证中心创建jwt,其他系统解析并校验,需要保持jwt同步。
综合总结:
- 方案1才是Jwt的本质。
- 方案2是我基于Jwt的改进,用作我们公司新项目的登录系统。
(个人比较推荐方案3,后续考虑会向方案3转移) - 方案3准确说是单点登录系统的标准流程,只是结合了Jwt。其他2种方案都是伪单点。
备注: 文中使用Redis是为了单个系统集群机器之间能够“Session共享”。
以上都是我的个人理解,自己记录总结下,希望不要误导大家。如有错误或不足,望轻喷,希望大佬能在评论区帮忙改进。
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/143558.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...