共计 2648 个字符，预计需要花费 7 分钟才能阅读完成。
- 认证与受权
首先小伙伴们晓得，无论咱们学习 Shiro 还是 Spring Security，里边的性能无论有哪些，外围都是两个：
认证
受权
所以，咱们在微服务中解决鉴权问题，也能够从这两个方面来思考。
1.1 认证
认证，说白了就是登录。传统的 Web 登录是 Cookie+Session 的计划，这种计划依赖于服务器本地内存，在微服务中，因为服务泛滥，这种计划显然不再适合。
可能会有小伙伴说用 Redis+SpringSession 做 Session 共享，这是个方法，然而不是最佳计划，因为这种计划的性能以及可扩展性都比拟差。
所以，微服务中的认证，还是倡议应用令牌的形式，能够抉择 JWT 令牌，这也是目前应用较多的一种计划。然而相熟 JWT 的小伙伴都晓得，纯正的无状态登录无奈实现登记，这就很头大，所以在理论利用中，单纯的应用 JWT 是不行的，个别还是要联合 Redis 一起，将生成的 JWT 字符串在 Redis 上也保留一份，并设置过期工夫，判断用户是否登录时，须要先去 Redis 上查看 JWT 字符串是否存在，存在的话再对 JWT 字符串做解析操作，如果能胜利解析，就没问题，如果不能胜利解析，就阐明令牌不非法。
这样有状态登录 + 无状态登录混在一起的形式，尽管看起来有点不三不四，然而就当下来说，这个折衷的方法算是一个可行的计划了。
其实，下面的计划，说白了，跟传统的 Cookie+Session 没什么两样，思路简直都是齐全 copy 的：传统的 Session 用 Redis 代替了；传统穿梭于服务端和浏览器之间的 jsessionId 被 JWT 字符串代替了；传统的 jsessionId 通过 Cookie 来传输，当初的 JWT 则通过开发者手动设置后通过申请头来传输；传统的 Session 能够主动续签，当初用 JWT 就是手动续签，每次申请达到服务端的时候，就去看下 Redis 上令牌的过期工夫，快过期了，就从新设置一下，其余都截然不同。
这是认证计划的抉择。
1.2 受权
微服务中受权，也能够应用 Shiro 或者 Spring Security 框架来做，省事一些。思考到微服务技术栈都是 Spring 家族的产品，所以在权限框架这块也是倡议大家首选 Spring Security（如果有小伙伴对 Spring Security 还不相熟的话，能够在微信公众号后盾回复 ss，有教程）。
当然，如果感觉 Spring Security 比较复杂想本人搞的话，也是能够的。本人搞的话，也是能够借助于 Spring Security 的思路的，松哥最近的一个我的项目就是这样：
申请达到微服务之后，先找到以后用户的各种信息，包含以后用户所领有的角色和权限等信息，而后存入到和以后线程绑定的 ThreadLocal 对象中。另一方面自定义权限注解和角色注解，在切面中对这些注解进行解析，查看以后用户是否具备所须要的角色 / 权限等。
当然，如果你应用了 Spring Security 的话，下面这个就不须要自定义注解了，间接应用 Spring Security 中自带的即可，还能够体验 Spring Security 中更多的丰盛的平安性能。
- 认证服务
那么认证和受权在哪里做？
先来说认证，认证咱们能够简略分为两个步骤：
登录
校验
2.1 登录
一般来说，登录咱们能够独自做一个认证服务。当登录申请达到网关之后，咱们将之转发到认证服务上，实现认证操作。
在认证服务上，咱们就去查看用户名 / 明码是否 OK，用户状态是否都 OK，都没问题的话，生成 JWT 字符串，同时再把数据存入到 Redis 上，而后把 JWT 字符串返回。
如果零碎有注册性能的话，注册性能也是放在这个微服务上来实现。
2.2 校验
校验是指每一个申请达到的时候，校验用户是否曾经登录。
这个当然能够和 2.1 放到一起去做，然而松哥不倡议。问题在于，如果是一个创立订单的申请，这个申请本来是要通过网关转发到订单服务上的，然而，此时就得先在网关上调用 2.1 大节的服务进行登录校验，没问题再转发到订单服务上，这样做很显著很麻烦，也不合理。
一个比拟好的方法是间接在网关下来校验申请的令牌是否非法，这个校验自身也比拟容易，校验令牌是否非法，咱们只须要看 Redis 上是否存在这个令牌，并且这个 JWT 令牌可能被顺利解析就行，这个操作齐全能够在网关上做。
以 Gateway 网关为例，咱们能够自定义全局过滤器，在全局过滤器中校验每一个申请的令牌，校验通过了，再进行申请的转发，否则就不转发。
校验通过之后，在转发到具体的微服务之后，咱们能够将解析进去的用户 id 以及用户名等信息放到申请头中，而后再转发，这样达到各个具体的微服务之后，就晓得这个申请是谁发来的，这人都有哪些角色 / 权限，不便做下一步的权限校验。
松哥的做法是定义了一个公共模块，所有的微服务都依赖这个公共模块，这个公共模块中定义了一个拦截器，会拦挡下来每一个申请，从申请头中取出用户 ID，而后从 Redis 中拿到具体的用户信息，存入到 ThreadLocal 中，这样在后续的办法调用中，如果须要判断用户是否具备某一个权限，就能够通过 ThreadLocal 去获取了。
大抵上就是这样一个流程。
- 受权服务
受权没法放到网关上做，还是得在各个微服务下来实现。
微服务上的受权咱们又能够将之大抵上分为两类：
前端发送来的申请（内部申请）。
别的微服务发送来的申请（外部申请）。
3.1 内部申请
对于内部申请来说，就按失常的权限校验看待就行了，自定义注解亦或者应用 Spring Security 等框架都是能够的，如果是自定义注解的话，就联合 AOP 一起，定义切面本人去解决权限注解，当然，这些性能基本上每一个微服务都是须要的，所以能够将之抽取成为一个公共的模块，在不同的微服务中依赖即可。
3.2 外部申请
对于外部的申请来说，失常是不须要鉴权的，外部申请能够间接解决。问题是如果应用了 OpenFeign，数据都是通过接口裸露进来的，不鉴权的话，又会放心从内部来的申请调用这个接口，对于这个问题，咱们也能够自定义注解 +AOP，而后在外部申请调用的时候，额定加一个头字段加以辨别。
当然，外部申请达到微服务的时候，也是须要进行认证的，就行申请从网关转发到每一个具体的微服务上时须要认证一样，不过很显著，咱们没必要每次应用 OpenFeign 调用别的服务的时候，都去传一堆认证信息，咱们能够通过实现 feign.RequestInterceptor 接口来定义一个 OpenFeign 的申请拦截器，在拦截器中，对立为 OpenFeign 申请设置申请头信息。
好啦，对于微服务中的鉴权，咱们目前是这么做的，欢送小伙伴们留言一起探讨。
