接口的安全问题

1.请求的身份是否合法？

2. 请求参数是否被篡改？

3. 请求是否唯一？

1. 请求身份

使用token的签名认证，使用加密算法生成签名。

2. 防止篡改

参数签名：请求携带参数token 和 sign ,只有拥有合法的身份token 和正确的签名sign才能放行，这样就解决了身份验证和参数篡改问题，即使请求参数被劫持，由于获取不到，加密算法，无法伪造合法的请求。

重放攻击

虽然解决了请求参数被篡改的隐患，但是还存在着重复使用请求采纳数伪造二次请求的隐患。

timestamp + nonce方案

nonce指唯一的随机字符串，用来标识每个被签名的请求。通过每个请求提供一个唯一的标识符，服务器能够防止请求被多次使用(记录所有用过的nonce以阻止他们被二次使用)然而对服务器来说永久存储所有接收到的nonce的代价是非常大的。可以使用timestamp来优化nonce的存储。

假设允许客户端和服务端最多能存在15分钟的时间差，同时追踪记录在服务端的nonce集合。当有新的请求进入时，首先检查携带的timestamp是否在15分钟内，如超出时间范围，则拒绝，然后查询携带的nonce，如存在已有集合，则拒绝。否则，记录该nonce，并删除集合内时间戳大于15分钟nonce(可以使用redis的expire，新增nonce的同时设置他的超时失效时间15分钟)

在APP开放API接口的设计中，由于大多数接口设计到用户的个人信息以及产品的敏感数据，所以要对这写接口进行身份验证，为了安全起见让用户暴露的明文密码次数越少越好，然后客户端与服务器的交互在请求之间是无状态的，也就是说，当涉及到用户状态时，每次请求都要带上身份验证信息

token身份验证

1. 用户登录向服务器提供认证信息(账号和密码)，服务器验证成功后返回Token给客户端

2. 客户端将Token保存在本地，后续发起请求时，携带此Token

3. 服务器检查Token的有效性，有效则方放行，无效则拒绝

安全隐患： Token被劫持，伪造请求和篡改参数

实现

登录和登出请求

 

 

后续请求

客户端

和上述的开放平台的客户端行为类似

服务端