微服务统一鉴权方案

user， team， role， role group

team就是user的集合，team拥有的角色每个member都会自动拥有
role group就是role的集合，user或者team拥有某个role group就表示他拥有group里面的所有角色。
team的作用：批量把一个角色assign给多个user
role group的作用： 批量把多个角色assign给user

统一鉴权中心

authorization_service负责用户登陆，登陆成功以后发给前端token，以后所有用户的请求都携带此token。其他服务根据token向authorization_service查询用户的权限

user authorization_service other_service login request token 携带token，request 携带token，permission_slug, 可以允许吗？ 可以 response user authorization_service other_service

role, permission_slug

用户是否可以进行某个操作，其实是根据用户是否拥有某个role来决定的，所以当某个服务判断某个用户是否具有某个操作的权限的时候，有以下几种方案：
1， service向authorization_service获得该用户的roles，自己判断。
2，service向authorization_service提供该操作需要的roles，由authorization_service判断后返回一个true或者false。
3，service向authorization_service提供该操作的名称，即permission_slug，authorization_service判断该操作需要的role，继而判断该用户是否拥有权限，然后返回给service判断结果。
由此可见，方案3的中心化程度最高，authorization_service可以提供一个统一的permission_slug -> roles配置中心，各个service甚至都不用理解role的概念。

前端

可以为每一个页面（甚至是子页面或者section）设置一个permission_slug，以同样的方法请求authorization_service来判断用户是否有权限访问。但是通常也没必要，因为前端是必须要理解role概念的，很多时候前端需要自己判断页面的访问权限，而不是请求后端，因为请求后端反而会把事情搞复杂。

限制

permission_slug还是比较粗粒度的权限控制，并不适用于所有情况，比如，订单详情页，那么查看该订单详情的人就只能是
1，用户本人
2，用户的管理者， 比如用户属于某个team，那么team leader是可以查看的
3，admin后台管理人员
这种情况就需要service自己判断了，service可以根据token从authorization_service获取user的具体信息。总之，对role的配置以及对用户的授权只在authorization_service处理，其他服务只能查询。