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。

网关Token和 服务间鉴权结合

我们都知道网关适合做认证和鉴权，但是在安全层面，我们要求更严格的权限，对于有些项目来说，本身网络跟外部隔离，再加上其它的安全手段，所以我们只要求在网关上鉴权就可以了。

但是有些时候服务对 服务之间的调用进行鉴权，知道某个用户是否有权限调用某个接口，这些都需要进行鉴权。

这时的方案如下。

1）在gateway网关层做认证，通过用户校验后，传递用户信息到header中，后台做服务在收到header后进行解析，解析完后查看是否有调用此服务或者某个url的权限，然后完成鉴权

2）从服务内部发出的请求，在出去时进行拦截，把用户信息保存在header里，然后传出去,被调用方取到header后进行解析和鉴权