REST API 安全设计指南。REST的全称是REpresentational State Transfer，它利用传统Web特点，提出提出一个既适于客户端应用又适于服务端的应用的、统一架构，极大程度上统一及简化了网站架构设计。
目前在三种主流的Web服务实现方案中，REST模式服务相比复杂的SOAP和XML-RPC对比来讲，更加简洁，越来越多的web服务开始使用REST设计并实现。但其缺少安全特性，《REST API 安全设计指南》就是一个REST API安全设计的指南，权当抛砖引玉，推荐网站后台设计及网站架构师们阅读。
文章目录
1，REST API 简介
REST的全称是REpresentational State Transfer，表示表述性无状态传输，无需session，所以每次请求都得带上身份认证信息。rest是基于http协议的，也是无状态的。只是一种架构方式，所以它的安全特性都需我们自己实现，没有现成的。建议所有的请求都通过https协议发送。RESTful web services 概念的核心就是“资源”。 资源可以用 URI 来表示。客户端使用 HTTP 协议定义的方法来发送请求到这些 URIs，当然可能会导致这些被访问的”资源“状态的改变。HTTP请求对应关系如下：
========== ===================== ========================
HTTP 方法 行为 示例
========== ===================== ========================
GET 获取资源的信息
GET 获取某个特定资源的信息
POST 创建新资源
PUT 更新资源
DELETE 删除资源
========== ====================== ======================= 对于请求的数据一般用json或者xml形式来表示，推荐使用json。
身份认证包含很多种，有HTTP Basic，HTTP Digest，API KEY，Oauth，JWK等方式，下面简单讲解下：
2.1 HTTP BasicREST由于是无状态的传输，所以每一次请求都得带上身份认证信息，身份认证的方式，身份认证的方式有很多种，第一种便是http basic，这种方式在客户端要求简单，在服务端实现也非常简单，只需简单配置apache等web服务器即可实现，所以对于简单的服务来说还是挺方便的。但是这种方式安全性较低，就是简单的将用户名和密码base64编码放到header中。 base64编码前：Basic admin:admin
base64编码后：Basic YWRtaW46YWRtaW4=
放到Header中：Authorization: Basic YWRtaW46YWRtaW4= 正是因为是简单的base64编码存储，切记切记在这种方式下一定得注意使用ssl，不然就是裸奔了。 在某些产品中也是基于这种类似方式，只是没有使用apache的basic机制，而是自己写了认证框架，原理还是一样的，在一次请求中base64解码Authorization字段，再和认证信息做校验。很显然这种方式有问题，，认证信息相当于明文传输，另外也没有防暴力破解功能。
API Key就是经过用户身份认证之后服务端给客户端分配一个API Key，类似：?key=dfkaj134,一般的处理流程如下： 一个简单的设计示例如下： client端：
client端向服务端注册，服务端给客户端发送响应的api_key以及security_key，注意保存不要泄露，然后客户端根据api_key,secrity_key,timestrap,rest_uri采用hmacsha256算法得到一个hash值sign，构造途中的url发送给服务端。 服务端收到该请求后，首先验证api_key,是否存在，存在则获取该api_key的security_key，接着验证timestrap是否超过时间限制，可依据系统成而定，这样就防止了部分重放攻击，途中的rest_api是从url获取的为/rest/v1/interface/eth0,最后计算sign值，完之后和url中的sign值做校验。这样的设计就防止了数据被篡改。 通过这种API Key的设计方式加了时间戳防止了部分重放，加了校验，防止了数据被篡改，同时避免了传输用户名和密码，当然了也会有一定的开销。
2.3 Oauth1.0a或者Oauth2OAuth协议适用于为外部应用授权访问本站资源的情况。其中的加密机制与HTTP Digest身份认证相比，安全性更高。使用和配置都比较复杂，这里就不涉及了。
2.4 JWTJWT 是JSON Web Token，用于发送可通过数字签名和认证的东西，它包含一个紧凑的，URL安全的JSON对象，服务端可通过解析该值来验证是否有操作权限，是否过期等安全性检查。由于其紧凑的特点，可放在url中或者 HTTP Authorization头中，具体的算法就如下图
身份认证之后就是授权，根据不同的身份，授予不同的访问权限。比如admin用户，普通用户，auditor用户都是不同的身份。简单的示例： php
$roles = array(
‘ADMIN‘=>array(
‘permit‘=>array(‘/^((\/system\/(clouds|device)$/‘), // 允许访问哪些URL的正则表达式
‘deny‘=>array(‘/^(\/system\/audit)$/‘) // 禁止访问哪些URL的正则表达式
),
‘AUDIT‘=>array(
‘permit‘=>array(‘/^(\/system\/audit)$/‘),//允许访问的URL正则表达式
‘deny‘=>array(‘/^((\/system\/(clouds|device).*)$/‘)
)
); 上述是垂直权限的处理，如果遇到了平行权限的问题，如用户A获取用户B的身份信息或者更改其他用户信息，对于这些敏感数据接口都需要加上对用户的判断，这一步一般都在具体的逻辑实现中实现。