我读过很多关于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的组合。 另外两个方案都是伪单点。 备注：本文使用Redis是为了能够在一台系统集群计算机之间进行“Session共享”。
以上都是我个人的理解，我想自己记录总结，不要误会大家。 如果有错误或不足的地方，请轻喷。 我希望大人物能在评论区帮助我改进。