web api安全性需要考虑的内容
- 验证调用合法性
- 防篡改 ,包括request 和response
- 防重放（DDOS)
- 防读
等
HOW?
做签名
client 选取request的需要防篡改的参数拼接random key按一定的算法生成salt（sign),服务端按照相同的方式（服务端保存了秘钥), 生成salt(sign),匹配下是否是一致
几个问题
1 token 何时下发？
分需要登陆型APP，以及非登陆型APP;登陆型app在登陆成功后，把token下发给client，非登陆型就需要一个专门下发token的接口
2 token 下发如何保护？
要保证一般的客户端-服务器通信安全，可以使用3个密钥。
初始密钥是第一个，内置到app，保证最初的通信安全，用来加密-“主加密密钥”。此过程中的传输，是最容易被攻击的环节，可以采用其他辅助方式进行加密, 如HTTPS等。
其次是主加密密钥， 系统初始化之后从服务端获取生成。保存在客户端。重复利用。用来加密通信密钥。也可以由用户主动更新。
还有第三个是通信密钥，每次登陆更新，或者定期更换，用来加密通信数据。 此密钥的传输过程使用主加密密钥来加密。
通信密钥就是用来加密通信数据的。
3 token 有效期？
- 只用一次
- 设置一段时间有效
4 签名算法暴露在客户端？
- 对于安卓客户端来说，签名的生成算法是用C写，二进制的反编译的难道高
- 对于web page，JS混淆难度高，也是容易破解的
所以这套机制适合于基于定制浏览器的app或者原生的的app
5 token表的存储
token的存储可以通过用户或者设备的id来进行映射，所以请求里面需要携带表示用户或者设备的id
补充机制
- 给请求加上timestamp。timestamp 是请求的有效截止响应时间，就是后台先提取这个时间，如果后台发现这个时间大于当前的系统时间，就拒绝响应,起到防部分重放攻击的作用
- 整套机制的实现成本高，可以考虑剪裁机制，做到一定的保护
机制实现的难点
- 服务降级
- 监控
salt 生成算法的选择
- SHA
- md5
- AES
===
业内动向
- JWT(JSON Web Token) 官网直达