微服务架构授权是在网关做还是在微服务做？

在SpringCloud架构中，实现授权功能有两种实现方式：

• 在网关层进行授权
• 由后端微服务自己授权

两种方式在此系列文章中都有实现方案，那么问题来了：哪种才是最优方案，哪种方案更合理呢？

很抱歉，看完这篇文章你也不一定能得到你想要的答案，因为结论是并没有最优方案，两种方案各有千秋，只有根据自身业务选择对应的方案。本文我们将两种方案做一个简单对比，以便大伙在做方案决策有个选择参考。

解决方案对比

首先我们看看两种方案实现的原理：如果对具体实现方式有疑问的同学可以参考这篇文章：SpringCloud Alibaba微服务实战十九 - 集成RBAC授权

网关授权

基于网关授权我们又叫基于路径匹配器授权，请求在经过网关的时候校验当前请求的路径是否在用户拥有的资源路径中。

在基于路径匹配器授权时需要考虑restful风格的访问路径，如 /account-service/blog/user/{id} 或 /account-service/blog/**等，所以在网关进行授权主要是基于通配符匹配。

微服务授权

微服务授权我们又叫基于方法拦截，在资源上打上对应的方法标识然后分配给用户。在请求方法上通过对应的注解判断当前用户是否有访问此方法的权限。如SpringSecurity中的 @PreAuthorize("hasAuthority('')")注解，Shiro中的 @RequiresPermissions('')注解。不管是SpringSecurity还是Shiro他们实现原理都是基于关键字完全匹配。

优缺点对比

网关授权

优点

使用网关授权的优点很明显，后端所有微服务只需要是普通的服务即可，不再需要依赖权限那一套。

缺点

1. 通配符匹配在网关做性能比较差，通配符要拆分，先匹配前缀，前缀匹配了再匹配通配符。
   这里大家可以看看 org.springframework.util.AntPathMatcher#doMatch()的实现逻辑。

2. 对于Restful风格的URL路径，不能精细化控制权限
   例如一个微服务有如下API
   GET /v1/pb/user
POST /v1/pb/user
PUT /v1/pb/user
   这样在网关通过 request.getURI().getPath()方法获取到用户请求路径的时候都是同一个地址，给一个用户授予 /v1/pb/user权限后他就拥有了 GET、PUT、POST三种不同权限，很显然这样不能满足精细权限控制。

   至于如何解决这个问题，原来专门写过一篇文章讨论，感兴趣的同学可以看看：SpringCloud Alibaba微服务实战二十五 - Restful接口拦截

微服务授权

优点：

上面提到网关授权的缺点实际上是微服务授权的优点，基于方法拦截是完全匹配，cpu消耗很少，而且也不存在RestFul的问题。

缺点：

实现较为复杂，在 SpringSecurity Oauth2体系中需要全部引入资源服务器相关配置，所以一般会建立一个单独的资源服务器模块，这也是系列文章下篇内容需要解决的问题。

结论

这里我们尝试对两种实现方案做一个总结，如果系统功能、业务模块不是很多可以采用网关授权模式，这样实现最简单也最方便，虽然存在Restful风格不能精细化权限控制问题，但是我们加一个Method字段就可以解决。

如果你的系统规模比较大，有很多资源需要授权那就建议采用微服务授权模式，为了避免每个微服务都需要处理权限校验的逻辑，我们需要抽取一个公共的权限认证模块供后端服务引用。