看过不少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共享”。
以上都是我的个人理解，自己记录总结下，希望不要误导大家。如有错误或不足，望轻喷，希望大佬能在评论区帮忙改进。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
如需转载请保留出处：https://bianchenghao.cn/hz/127519.html