看过不少JWT和单点登录系统的文章，自己也算略知一二。

这里就根据自己的实际开发经验谈一下我的理解。

大致可以总结为以下三种方案：

1. 纯Jwt

2. Jwt + 认证中心Redis

3. Jwt + 认证中心Redis + 多系统Redis

1. 纯Jwt 方案

1. 用户去认证中心登录，认证中心生成jwt，返回给客户端。

2. 客户端携带jwt请求多个系统  

3. 每个系统各自解析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同步。

综合总结：

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