背景

本文主题是作者在 Spring Cloud 体系下通过 Zuul 网关来进行认证的迁移授权的前移、统一管理和业务服务进行鉴权的思考和做法。
本文介绍的做法是根据 Zuul 来做的，对 Zuul 不熟悉的朋友可以看看下面这篇文章，通过这篇对 Zuul 深入浅出的介绍之后能对 Zuul 有个大致的了解。
出自方志朋的博客:深入理解Zuul之源码解析

核心思想

本人认为微服务中权限的处理应该分为两种：

• 用户的权限控制
• 系统服务的权限控制

具体思路

先上图

Zuul+微服务鉴权.png UML时序图.png

• 由图中可以看出将请求简单的定义为内部请求和外部请求。

再来分析外部请求（token）

• 本人将 token 理解成认证的令牌，token 完全由 Zuul 来具体管理（新建、刷新和销毁）与其他服务无关，但是 Zuul 中处理 token 的动作指令由业务服务发出。
• 用户登录：用户请求登录，Cookie 中无 token，Zuul 不对其进行认证（即这个人我不认识，我不管），将请求投递路由到业务服务，业务服务该接口不会校验其权限，通过登录逻辑处理，登录成功返回，响应头中增加了登录成功标示和该用户权限角色信息（authentication 后文通过该单词代替 ），Zuul 接收到信息之后新建 token，并将token与authentication对应起来。
• 用户请求信息：Cookie 中有 token，校验token的有效性，如果成功将取出对应的authentication，设置进路由的请求头中，业务系统通过请求头解析出该用户的身份，并鉴权。
• 用户退出登录：请求部分与用户请求信息一致，返回时将在响应头中设置注销登录标示，Zuul 获取标示之后会销毁token与其对应authentication。

最后分析内部请求

• 由于是内部请求，于是将安全校验的机制设置得相对简单了。
• 将每个Service理解为一个独立的第三方服务系统，调用Service理解为请求客户系统。
• 凡是想调用某个Service之前，必须先去申请一个secretKey，然后每个请求都必须携带该secretKey，通过secretKey可以查出调用者，控制调用系统权限。
• 补充：有人觉得通过一个secretKey来处理不够安全，对于内部请求安全级别高的，可以对应secretKey设置 ip白名单，甚至设置secretKey的有效时间通过系统刷新来刷新secretKey，个人感觉大部分的企业不需要来刷新secretKey来提高安全级别，通过 ip白名单的方式安全程度已经够高了。

总结

• 本文只介绍了作者在改造系统权限体系时的想法思路，文中 Zuul 可以就理解为网关，后面系列将介绍如何在 Zuul 中实现，这里具体实现就没有提及了。
• 作者的token处理参考了Oauth2.0 协议的token机制，即具备刷新过期等机制，如果感觉本文有那么一些道理，想继续看看我是怎么做的话，可以继续关注，后面有计划将整个实现机制开源出来。
• 文中的想法很多是我与公司团队的想法，欢迎大家与我交流分享，热烈欢迎指正不对之处。