API接口签名验证

系统从外部获取数据时，一般采用API接口调用的方式来实现。请求方和接口提供方之间的通讯过程，有这几个问题须要考虑：

1. 请求参数是否被篡改；
2. 请求来源是否合法；
3. 请求是否具备惟一性；

今天跟你们探讨一下主流的通讯安全解决方案。

 

参数签名方式

这种方式是主流。它要求调用方按照约定好的算法生成签名字符串，做为请求的一部分，接口提供方验算签名便可知是否合法。步骤一般以下：
①接口提供方给出appid和appsecret
②调用方根据appid和appsecret以及请求参数，按照必定算法生成签名sign
③接口提供方验证签名
生成签名的步骤以下：
①将全部业务请求参数按字母前后顺序排序
②参数名称和参数值连接成一个字符串A
③在字符串A的首尾加上appsecret组成一个新字符串B
④对字符串进行md5获得签名sign
假设请求的参数为：f=1,b=23,k=33，排序后为b=23,f=1,k=33，参数名和参数值连接后为b23f1k33，首尾加上appsecret后md5：
md5(secretkey1value1key2value2...secret)。

以上签名方法安全有效地解决了参数被篡改和身份验证的问题，若是参数被篡改，没事，由于别人没法知道appsecret，也就没法从新生成新的sign。
这里使用了md5的算法进行签名，也能够自行选择其余签名方式，例如RSA，SHA等。

 

请求惟一性保证

md5签名方法能够保证来源及请求参数的合法性，可是请求连接一旦泄露，能够反复请求，对于某些拉取数据的接口来讲并非一件好事，至关因而泄露了数据。
在请求中带上时间戳，而且把时间戳也做为签名的一部分，在接口提供方对时间戳进行验证，只容许必定时间范围内的请求，例如1分钟。由于请求方和接口提供方的服务器可能存在必定的时间偏差，建议时间戳偏差在5分钟内比较合适。容许的时间偏差越大，连接的有效期就越长，请求惟一性的保证就越弱。因此须要在二者之间衡量。

 

秘钥的保存　

在签名的过程当中，起到决定性做用之一的是appsecret，所以如何保存成为关键。咱们分类讨论。
接口调用方的代码跑在服务器的状况比较好办，除非服务器被攻陷，不然外接没法知道appsecret，固然，要注意不能往日志里写入appsecret的值，其余敏感值也禁止写入日志，如帐号密码等信息。
假如是客户端请求接口，就须要多想一步了。假如把appsecret硬编码到客户端，会有反编译的风险，特别是android。能够在客户端登录验证成功后，返回给客户端的信息中带上appsecret(固然，返回的数据也可能被拦截，真是防不胜防啊。。。)。特别说明一下，在android开发中，假如硬要把appsecret硬编码，建议把appsecret放到NDK中编译成so文件，app启动后去读取。