背景
本文主题是作者在 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机制，即具备刷新过期等机制，如果感觉本文有那么一些道理，想继续看看我是怎么做的话，可以继续关注，后面有计划将整个实现机制开源出来。 - 文中的想法很多是我与公司团队的想法，欢迎大家与我交流分享，热烈欢迎指正不对之处。
