【接口安全】接口合法性验证加密验签SIGN 签名规则

在对接API接口时，接口地址和参数结构都很容易被黑客抓包，从而模拟发送请求。

考虑到安全性，防止别人冒名调用，要对接口请求进行合法性验证。

基本原理如下

双方约定

APPID：参与签名和网络传输

APPSecretKey：约定秘钥，保存在双发服务器，只参与签名，不参与网络传输

签名方法

调用API时，需要将所有参数名称以及参数值加入签名，
即：系统级参数（除去SIGN）名称、系统级参数值、应用级参数名称、应用级参数值全部加入签名。

签名参数排序

签名时，根据参数名称，将除签名（sign）外所有请求参数按照字母先后顺序排序: key + value .... key + value 。
注：
、排序若首字母相同，则对第二个字母进行排序，以此类推。
、value无需编码。
、对于非必选参数，如果没有value值，也参与签名。（说明：非必选参数没有value值时，将参数名放到字符串中，即参数名要参加签名）
例如：将“foo=,bar=,baz=三”排序为“bar=,baz=三,foo=”参数名和参数值链接后，得到拼装字符串bar2baz三foo1。

签名算法

将分配的得到的密钥（SecretKey）接到参数字符串尾部进行md5加密（UTF8编码），再转化成大写，
格式是：md5(key1value1key2value2...Secret)。

双方根据本次请求的参数采用相同的排序生成字符串，并用相同加密算法（一般MD5，也可以用多次加密处理），最后得到的消息摘要sign肯定是一样的，依次判断请求的合法性。

服务端在处理的时候要注意多次请求避免重复处理的情况，这时可以通过三方业务唯一标识ID去区分处理，接口响应要保持幂等性（在编程中.一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。）。

当然上面的加密方式消息体依然是明文传输的，如果有重要信息，还是有泄露信息的可能性存在。

更高级的方法是参考HTTS的原理，通过公钥、私钥进行消息体的加密处理。可参考之前写的HTTS加密原理 http://www.cnblogs.com/jhli/p/6575828.html

搞定！