REST API权限控制
前言
有人说，每个人都是平等的；也有人说，人生来就是不平等的；在人类社会中，并没有绝对的公平，一件事，并不是所有人都能去做；一样物，并不是所有人都能够拥有。每个人都有自己的角色，每种角色都有对某种资源的一定权利，或许是拥有，或许只能是远观而不可亵玩。把这种人类社会中如此抽象的事实，提取出来，然后写成程序，还原本质的工作，就是我们程序员该做的事了。有了一个这么有范儿的开头，下面便来谈谈基于RESTful，如何实现不同的人不同的角色对于不同的资源不同的操作的权限控制。
RESTful简述
本文是基于RESTful描述的，需要你对这个有初步的了解。RESTful是什么？Representational State Transfer，简称REST，是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。REST比较重要的点是资源和状态转换，所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。而 “状态转换”，则是把对应的HTTP协议里面，四个表示操作方式的动词分别对应四种基本操作：
- GET，用来浏览(browse)资源
- POST，用来新建(create)资源
- PUT，用来更新(update)资源
- DELETE，用来删除(delete)资源
资源的分类及操作
清楚了资源的概念，然后再来对资源进行一下分类，我把资源分为下面三类：
- 私人资源 (Personal Source)
- 角色资源 (Roles Source)
- 公共资源 (Public Source)
“私人资源”：是属于某一个用户所有的资源，只有用户本人才能操作，其他用户不能操作。例如用户的个人信息、订单、收货地址等等。“角色资源”：与私人资源不同，角色资源范畴更大，一个角色可以对应多个人，也就是一群人。如果给某角色分配了权限，那么只有身为该角色的用户才能拥有这些权限。例如系统资源只能够管理员操作，一般用户不能操作。“公共资源”：所有人无论角色都能够访问并操作的资源。
而对资源的操作，无非就是分为四种：
- 浏览 (browse)
- 新增 (create)
- 更新 (update)
- 删除 (delete)
角色、用户、权限之间的关系
角色和用户的概念，自不用多说，大家都懂，但是权限的概念需要提一提。
“权限”，就是资源与操作的一套组合，例如"增加用户"是一种权限，"删除用户"是一种权限，所以对于一种资源所对应的权限有且只有四种。
角色与用户的关系：一个角色对应一群用户，一个用户也可以扮演多个角色，所以它们是多对多的关系。
角色与权限的关系：一个角色拥有一堆权限，一个权限却只能属于一个角色，所以它们是一(角色)对多(权限)的关系
权限与用户的关系：由于一个用户可以扮演多个角色，一个角色拥有多个权限，所以用户与权限是间接的多对多关系。
需要注意两种特别情况：
- 私人资源与用户的关系，一种私人资源对应的四种权限只能属于一个用户，所以这种情况下，用户和权限是一(用户)对多(权限)的关系。
- 超级管理员的角色，这个角色是神一般的存在，能无视一切阻碍，对所有资源拥有绝对权限，甭管你是私人资源还是角色资源。
数据库表的设计
角色、用户、权限的模型应该怎么样设计，才能满足它们之间的关系？
对上图的一些关键字段进行说明：
Source
- name: 资源的名称，也就是其他模型的名称，例如：user、role等等。
- identity: 资源的唯一标识，可以像uuid，shortid这些字符串，也可以是model的名称。
- permissions : 一种资源对应有四种权限，分别对这种资源的browse、create、update、delete
Permission
- source : 该权限对应的资源，也就是Source的某一条记录的唯一标识
- action ：对应资源的操作，只能是browse、create、update、delete四个之一
- relation：用来标记该权限是属于私人的，还是角色的，用于OwnerPolicy检测
- roles: 拥有该权限的角色
Role
- users : 角色所对应的用户群，一个角色可以对应多个用户
- permissions: 权限列表，一个角色拥有多项权利
User
- createBy : 该记录的拥有者，在user标里，一般等于该记录的唯一标识，这一属性用于OwnerPolicy的检测，其他私有资源的模型设计，也需要加上这一字段来标识资源的拥有者。
- roles : 用户所拥有的角色
策略/过滤器
在sails下称为策略(Policy)，在java SSH下称为过滤器(Filter)，无论名称如何，他们工作原理是大同小异的，主要是在一条HTTP请求访问一个Controller下的action之前进行检测。所以在这一层，我们可以自定义一些策略/过滤器来实现权限控制。
为行文方便，下面姑且允许我使用策略这一词。
** 策略 (Policy) **
下面排版顺序对应Policy的运行顺序
- SessionAuthPolicy：
检测用户是否已经登录，用户登录是进行下面检测的前提。 - SourcePolicy：
检测访问的资源是否存在，主要检测Source表的记录 - PermissionPolicy：
检测该用户所属的角色，是否有对所访问资源进行对应操作的权限。 - OwnerPolicy：
如果所访问的资源属于私人资源，则检测当前用户是否该资源的拥有者。
如果通过所有policy的检测，则把请求转发到目标action。
JWT下的权限控制实现
JSON Web Token定义
JSON Web Token (JWT)是一个开放标准(RFC 7519)，它定义了一种紧凑的、自包含的方式，用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的。
Jwt数据结构
JSON Web Token由三部分组成，它们之间用圆点(.)连接。这三部分分别是：
- Header
- Payload
- Signature
因此，一个典型的JWT看起来是这个样子的：
xxxxx.yyyyy.zzzzz
Header
header典型的由两部分组成：token的类型（“JWT”）和算法名称（比如：HMAC SHA256或者RSA等等）。
例如：
然后，用Base64对这个JSON编码就得到JWT的第一部分
Payload
JWT的第二部分是payload，它包含声明（要求）。声明是关于实体(通常是用户)和其他数据的声明。声明有三种类型: registered, public 和 private。
- Registered claims : 这里有一组预定义的声明，它们不是强制的，但是推荐。比如：iss (issuer), exp (expiration time), sub (subject), aud (audience)等。
- Public claims : 可以随意定义。
- Private claims : 用于在同意使用它们的各方之间共享信息，并且不是注册的或公开的声明。
下面是一个例子：
对payload进行Base64编码就得到JWT的第二部分
注意，不要在JWT的payload或header中放置敏感信息，除非它们是加密的。
Signature
为了得到签名部分，你必须有编码过的header、编码过的payload、一个秘钥，签名算法是header中指定的那个，然对它们签名即可。
例如：
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
签名是用于验证消息在传递过程中有没有被更改，并且，对于使用私钥签名的token，它还可以验证JWT的发送方是否为它所称的发送方，看一张官网的图就明白了。
JSON Web Tokens是如何工作的
在认证的时候，当用户用他们的凭证成功登录以后，一个JSON Web Token将会被返回。此后，token就是用户凭证了，你必须非常小心以防止出现安全问题。一般而言，你保存令牌的时候不应该超过你所需要它的时间。
无论何时用户想要访问受保护的路由或者资源的时候，用户代理（通常是浏览器）都应该带上JWT，典型的，通常放在Authorization header中，用Bearer schema。
header应该看起来是这样的：
Authorization: Bearer
服务器上的受保护的路由将会检查Authorization header中的JWT是否有效，如果有效，则用户可以访问受保护的资源。如果JWT包含足够多的必需的数据，那么就可以减少对某些操作的数据库查询的需要，尽管可能并不总是如此。
如果token是在授权头（Authorization header）中发送的，那么跨源资源共享(CORS)将不会成为问题，因为它不使用cookie。
下面这张图显示了如何获取JWT以及使用它来访问APIs或者资源。
- 应用（或者客户端）想授权服务器请求授权。例如，如果用授权码流程的话，就是/oauth/authorize
- 当授权被许可以后，授权服务器返回一个access token给应用
- 应用使用access token访问受保护的资源（比如：API）
结语
对程序员最大的挑战，并不是能否掌握了哪些编程语言，哪些软件框架，而是对业务和需求的理解，然后在此基础上，把要点抽象出来，写成计算机能理解的语言。
最后，希望这篇文章，能够帮助你对权限管理这一课题增加多一点点理解。