JWT单点登录的三种解决方案

 看过不少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. 方案1才是Jwt的本质。
2. 方案2是我基于Jwt的改进，用作我们公司新项目的登录系统。
   （个人比较推荐方案3，后续考虑会向方案3转移）
3. 方案3准确说是单点登录系统的标准流程，只是结合了Jwt。其他2种方案都是伪单点。

备注： 文中使用Redis是为了单个系统集群机器之间能够“Session共享”。

以上都是我的个人理解，自己记录总结下，希望不要误导大家。如有错误或不足，望轻喷，希望大佬能在评论区帮忙改进。