看过不少JWT和单点登录系统的文章,自己也算略知一二。
这里就根据自己的实际开发经验谈一下我的理解。
大致可以总结为以下三种方案:
1. 纯Jwt
2. Jwt + 认证中心redis
3. Jwt + 认证中心Redis + 多系统Redis
1. 用户去认证中心登录,认证中心生成jwt,返回给客户端。
2. 客户端携带jwt请求多个系统
3. 每个系统各自解析jwt,取出用户信息。能解析成功就说明jwt有效,继续处理
自己的业务逻辑。
优点:认证流程简单,服务端处理速度快。
缺点:因为简单,所以不安全。jwt一旦下发,有效期内就无法使其主动失效。
一句话总结:认证中心创建Jwt,其他系统解析。
1. 用户去认证中心登录,认证中心生成jwt,保存到redis并返回给客户端。
2. 客户端携带jwt去多个系统认证
3. 每个系统只负责从请求中取出jwt, 传给认证中心。认证解析用户信息,
并与redis中的jwt校验,判断是否有效。然后返回用户信息给刚才发起验证请求的系统。
优点:安全性高,服务端能控制jwt主动失效。
缺点:每次请求需要认证的接口,都需要访问认证中心,耗时略长。
一句话总结:认证中心负责Jwt的创建与解析,其他系统不参与认证逻辑。
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共享”。