从单体应用到SOA应用再到Spring Cloud微服务构架，应用的安全访问都是非常重要的问题，怎么样设计微服务的权限控制？首先，权限控制可以分为三个部分：用户认证，服务权限，用户权限。

用户认证

用户认证，简单的讲，可以简化为应用对用户登录状态的认证。传统的单体应用，使用session来进行用户认证，但是这种方式已经不适合微服务的场景了；微服务的结构下，可以通过分布式session来解决，也可以通过和Spring Cloud Security结合很好的OAuth2来解决。

分布式Session

通过单独开辟一个认证服务或者公共存储的方式实现。一般流程为：

1，用户登录，验证成功 2，服务器给用户客户端分发令牌token，并将token以及其他信息存储到认证服务或者公共缓存中 3，客户端请求时带服务器分发的token，请求服务 4，服务拿到用户token，并通过认证服务或者公共缓存中存储的token来校验用户token 5，token校验成功，执行服务逻辑，返回结果

用分布式session实现时，需要仔细考量的是，校验token的逻辑在什么阶段校验比较合适？一般有两个选择，放在各自的微服务校验，和放在zuul网关校验。

在微服务上校验用户token的话，还要考虑到要与服务调用服务的场景区分，增加了校验的复杂程度，所以选择将用户认证统一放在zuul网关校验。这样，业务流程就如下图。

JWT

JWT（JSON Web Tokens），简单的说就是服务器不存储任何数据，将数据保存在客户端，每次请求发回服务端。

JWT的原理是，服务器认证后生成一个json对象（保存着用户信息，登录过期时间等），json对象发回给用户客户端，以后客户端与服务器进行通信的时候，都需要带着json对象，这样服务器就可以完成用户的认证。

这样，服务器不保存任何数据，这样服务器就无状态了，比较易于扩展。

但是数据保存在客户端，用户修改JSON对象的数据很不安全，为了保证用户不篡改json对象的内容，服务器在生成对象的时候会加上签名加密。

 

分布式session和JWT对比

分布式session的问题是，服务器保存用户认证数据，需要扩展的成本，如果认证服务或者缓存服务出现问题，整个应用就不可用，也就是单点故障问题。session的访问一般要存储在内存中，来支持快速的读写，这样也就不易于扩展。

JWT的缺点是，session只要是服务器发出去的JSON对象，服务器都要通过认证。如果用户信息量比较大的话，每次通过网络请求也不太合理

服务权限认证

微服务的一大核心是将服务进行拆分，降低服务的复杂度，拆分后，就会有服务之间的调用关系，服务之间的权限控制也是必要的。一般只需要维系微服务之间的调用关系，微服务调用时，调用发带着自己的服务标识，被调用发校验调用方的权限。

用户权限认证

用户权限一般分为功能权限和数据权限

功能权限

用户功能权限一般采用经典的RBAC（Role Based Access Control）方式进行控制，RBAC的核心就是通过角色来控制用户权限，也就是用户通过角色和权限产生关联，再去控制用户的操作。

RBAC的模型如下，通过这个模型最终用户和权限产生关系，结合前后端的权限校验，实现功能权限控制。

 

数据权限

用户的数据权限需要新建模型去控制，通过数据范围的模型去控制，核心是通过数据范围来控制数据权限，先定义好在哪些维度上进行数据权限的控制，数据范围有各个维度数据的数据集，根据这个数据集去控制用户的数据的访问范围。

这样，整合用户认证，微服务之间权限控制，用户权限控制后，微服务的权限控制整体结构为：

（完）