JWT + Zuul + Redis -- 鉴权方案 -- 微服务架构



JWT + Zuul + Redis

其实就是客户端 Token 与 API 网关结合的变相实现
因为大部分微服务内部直接调用都默认不用再次验证,因此没有必要再搞一个内部的 token,直接将数据取出来简单粗暴的进行交互!
但对于一些特殊的应用,服务与服务之间的调用也设计了权限,像这种情况生成内部 token 还是确实有必要的!

若对过期要求不高的场景,可以不使用 Redis,直接使用 JWT 的过期时间即可

登录流程:


  • 用户登录,网关判断是不是登录请求
  • 如果是,则访问跳转至认证微服务。在认证微服务验证验证通过后,生成 JWT(包括有效器,权限信息或者是转义后的权限信息等)返回,同时将一些隐私信息(包括用户联系方式、权限信息等)存入 redis 并设置过期时间(略大于 JWT 有效期即可),前端存储 JWT,以后的所有请求都需携带 JWT
  • 如果不是,则进行验证流程

验证流程:


检查用户请求是否携带 token,因为是 JWT ,网关可以判断 token 是否有效,无效则直接返回未登录,有效则向认证微服务请求验证,认证微服务从 redis 获取该 token 对应的隐私信息(主要是权限信息,这里因为隐私信息的有效是大于 JWT 的)认证通过后将隐私信息返回给网关,网关携带隐私信息再访问其它微服务


关键点描述说明

服务端如何控制 token 失效?

当用户修改密码后,直接将 redis 中的该用户的隐私信息删除掉即可!

当用户的权限被修改后,直接修改存储在 redis 中的权限即可,当用户下一次请求过来时,后端若发现权限变化了,则自动再生成一个 token 返回给前端,前端重新存储下 token。这样用户既可以不用重新登录,而且权限又得到了很好的控制!

为什么要将权限存入 redis?

有人可能会说,JWT 中已经有权限信息了,为什么我们还需要在 redis 中保存?JWT 不是基本上可以默认为是无法被篡改的吗?这个主意是考虑到用户的权限可能会发生变化,JWT 中的权限只是在前端用来控制 UI 元素显示或是否可点击的,因为我方案是要求 Token 失效是后台可以随意掌控的,不管权限放不放 redis,每次的 token 验证都是必须查 redis 的,因此将权限放入 redis 还可以动态改变!


Reference

https://www.jianshu.com/p/73f28fc56f8e