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启动后去读取。