【笔记】API 接口签名验证

写在前面：

很多时候在开发对外接口的时候，为了保证接口的安全以及服务的稳定，要对接口的访问添加一定的限制规则。

那么就有几个问题需要注意一下：

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

参数签名方式：

定义规则：

这种方式是主流。它要求调用方按照约定好的算法生成签名字符串，作为请求的一部分，接口提供方验算签名即可知是否合法。步骤通常如下：

1. 接口提供方给出 appid 和 appsecret
2. 调用方根据 appid 和 appsecret 以及请求参数，按照一定算法生成签名 sign
3. 接口提供方验证签名

生成签名的步骤如下：

1. 将所有业务请求参数按字母先后顺序排序
2. 参数名称和参数值链接成一个字符串 A
3. 在字符串 A 的首尾加上 appsecret 组成一个新字符串 B
4. 对字符串进行 md5 得到签名 sign
5. 假设请求的参数为：f=1,b=23,k=33，排序后为 b =23,f=1,k=33，参数名和参数值链接后为 b23f1k33，首尾加上 appsecret 后 md5：
6. md5(secretkey1value1key2value2…secret)。

以上签名方法安全有效地解决了参数被篡改和身份验证的问题，如果参数被篡改，没事，因为别人无法知道 appsecret，也就无法重新生成新的 sign。

这里使用了 md5 的算法进行签名，也可以自行选择其他签名方式，例如 RSA，SHA 等。

请求唯一性保证：

md5 签名方法可以保证来源及请求参数的合法性，但是请求链接一旦泄露，可以反复请求，对于某些拉取数据的接口来说并不是一件好事，相当于是泄露了数据。

在请求中带上时间戳，并且把时间戳也作为签名的一部分，在接口提供方对时间戳进行验证，只允许一定时间范围内的请求，例如 1 分钟。

因为请求方和接口提供方的服务器可能存在一定的时间误差，建议时间戳误差在 5 分钟内比较合适。允许的时间误差越大，链接的有效期就越长，请求唯一性的保证就越弱。所以需要在两者之间衡量。

秘钥的保存：

在签名的过程中，起到决定性作用之一的是 appsecret，因此如何保存成为关键。

我们分类讨论：

接口调用方的代码跑在服务器的情况比较好办，除非服务器被攻陷，否则外接无法知道 appsecret，当然，要注意不能往日志里写入 appsecret 的值，其他敏感值也禁止写入日志，如账号密码等信息。

假如是客户端请求接口，就需要多想一步了。假如把 appsecret 硬编码到客户端，会有反编译的风险，特别是 android。可以在客户端登陆验证成功后，返回给客户端的信息中带上 appsecret(当然，返回的数据也可能被拦截，真是防不胜防啊。。。)。

特别说明一下，在 android 开发中，假如硬要把 appsecret 硬编码，建议把 appsecret 放到 NDK 中编译成 so 文件，app 启动后去读取。

喜欢(2) 打赏