您的位置 : 文档中心 -> API 签名规则

API签名算法及工具

API签名算法及工具

API签名串组装规则

在1688开放平台,url请求的多个参数都要参与签名(与文件上传有关的api中,文件字节流那个参数不参与签名),下面以两个参数为例,假设请求的url格式如下所示:
http://gw.open.1688.com/openapi/param2/1/system/currentTime/1000000?b=2&a=1(appKey=1000000, 假设 secretKey=test123

参照签名算法说明,签名串s组装规则为:
1、 构造签名因子:urlPath。url 中的一部分,我们称之为urlPath,从协议(param2)开始截取,到“?”为止,urlPath=param2/1/system/currentTime/1000000
2、 构造签名因子:拼装的参数。参数 b=2&a=1,首先将参数的key和value拼在一起,得到b2和a1,然后按照首字母排序,得到a1和b2,最后按顺序拼在一起得到a1b2
3、 合并两个签名因子。把前两步的字符串拼起来,得到s = param2/1/system/currentTime/1000000a1b2
4、 对合并后的签名因子执行hmac_sha1算法。 Signature=uppercase (hex (hmac_sha1 (s, secretKey)) 得到签名33E54F4F7B989E3E0E912D3FBD2F1A03CA7CCE88
——secretKey为签名密钥,与urlPath中的appKey(1000000)对应
——hmac_sha1为通用的hmac_sha1算法,各编程语言一般都对应类库
——hex为转为十六进制
——uppercase为转为大写字符

说明:API签名算法主要是使用urlPath和请求参数作为签名因子进行签名,主要针对api 调用

参数签名算法及工具

参数签名算法及工具

参数签名串组装规则

在1688开放平台,用户在客户端访问app时app发起的授权请求url如下所示 :( 注意:只有客户端或WEB端授权流程中的"app发起授权请求"这一步的签名才使用此规则,参见 客户端流程详情
http://gw.open.1688.com/auth/authorize.htm?client_id=YOUR_CLIENT_ID&site=china&redirect_uri=YOUR_REDIRECT_URL&state=YOUR_PARAM&_aop_signature=SIGNATURE
注意:此处访问的是授权页面authorize.htm,并不是api调用,所以没有urlPath,不能用API签名算法,只是用请求参数作为签名因子进行签名。请求参数的拼装算法跟API签名一致

假设用户授权请求的参数为 client_id=10000&site=china&redirect_uri=http://localhost:8888&state=test( client_id为appKey,对应的签名密钥假设为 client_secret=abcd), 那么签名串的组装规则为 :
1、 构造签名因子:拼装的参数 。 参数 client_id=10000&site=china&redirect_uri=http://localhost:8888&state=test, key和value拼在一起得到 client_id10000&sitechina&redirect_urihttp://localhost:8888&statetest, 然后按照首字母排序,排序后为 client_id10000&redirect_urihttp://localhost:8888&sitechina&statetest, 然后将排序后的数组拼在一起 ,得到最终的签名因子 data=client_id10000redirect_urihttp://localhost:8888sitechinastatetest
2、 对最终的签名因子执行hmac_sha1算法 。 Signature=uppercase (hex (hmac_sha1 (data, client_secret)) 得到签名 CA538FE6B2180496B77EB46D0EBB5A2EA7A2418B
——client_secret为签名密钥,与值为10000(client_id参数的值)的appKey对应
——hmac_sha1为通用的hmac_sha1算法,各编程语言一般都对应类库
——hex为转为十六进制
——uppercase为转为大写字符

说明:参数签名算法只使用请求参数作为签名因子进行签名,仅针对客户端或WEB端授权时请求临时令牌code