Jwt单点登录的三种方案 _Jwt单点登录

看过不少JWT和单点登录系统的文章，自己也算略知一二。
这里就根据自己的实际开发经验谈一下我的理解。
大致可以总结为以下三种方案：

1. 纯Jwt
2. Jwt + 认证中心redis
3. Jwt + 认证中心Redis + 多系统Redis

1. 纯Jwt 方案【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同步 。

综合总结：