摘要：权限管理几乎出现再任何系统里，覆盖面极其广泛，各种安全策略数不胜数，权限管理包括权限验证和权限传递，权限传递可以后端存储权限，也可以用数字签名加密技术传递等，而权限验证变化多，但变来变去验证权限一般离不开几大类型，基于资源/基于操作/基于角色，大部分验证都是基于这三种情况演化而来。《JWT颁发以及权限校验实践》

权限传递

主要有两种手段，“服务端存储”形式和“数字签名”形式。区别在于服务端存储具有实时性，没有暴露的危险，而数字签名形式一旦颁发就没法取消，会有暴露的危险，但有过期时间，相对来说没那么安全。

服务端存储形式

就是后端对权限进行存储，介质可以有很多种。
session，这种直接存在后端，访问快，单体系统下还是比较适合，没法跨服务验证。
利用redis等外部介质存储，可以实现跨服务验证，外部媒介存储这种形式坏处在于有性能瓶颈的，还有对外请求也浪费时间。

数字签名形式

主要有两种HS256（对称加密）和RS256（非对称加密）。

对称加密----性能方面比RS256验证快大约1个数量级，安全性方面对称加密只有一组密钥，授权与验证端都必须是完全可信，否则一旦泄漏了密钥，就完蛋了。

非对称加密----性能方面比HS256签发（签名）快2个数量级，安全性方面它使用公用/专用密钥对，密钥加密数据，用公钥可以解密，公钥是公开的，加密方可以在申请token时候决定是否颁发给对方，从而控制了使用者。

权限验证

权限验证无非就是几种形式，基于资源的，基于角色的，基于操作的。他们的区别在于验证粒度与形式的区别。这三种是针对api的权限验证方式。

基于资源的权限验证

这种验证方式限制了权限种类，Read（只读），Write（可修改），Create（可创建），Delete（可删除），形式比较单一的验证方式。而且这种验证需要先查出这个资源的数据和相关信息才可以根据里边信息进行校验权限，资源种类各种各样，难以使用AOP形式进行统一验证。通常会写在业务逻辑里，封装难普适化。

基于角色的权限验证

基于角色与基于操作的区别在于粒度的区别，适用于那些比较粗粒度的权限，并且角色不多，像那种只有管理员和普通用户的就特别适用，一般互联网项目就是这些。

基于操作的权限验证

这种权限校验粒度比较高，每个接口都有自己的权限名字，由后台进行配置给用户权限，这种权限控制十分精细，但写起来麻烦，而且如果权限太多需要用jwt传递权限这种方式也是噩梦，权限非常多的情况下全丢到jwt body里，这串加密码非常庞大，所以这种方式适合于服务端存储形式，当然啦，你的企业发展到一定程度，有可能演化出多系统，每套系统都有属于自己的权限体系，但用于是公用的，这种情况可以结合jwt与服务端存储，jwt用于传递用户信息，具体权限在自己系统控制