10 接口调用鉴权
具体签名值的产生可参见服务器端demo示例程序（sigdemo4serverAES.zip）。
10.1 auth数字签名
功能描述：
Auth 校验算法主要是验证客户端的签名是否正确。客户端向服务端传输 HTTP 请求的时候，需要在头部传 输两个参数：x-hmac-auth-signature 和 x-hmac-auth-date 及其相应的值。而 x-hmac-auth-signature 的值是由 appid 和利用 auth 签 名 校 验 算 法 生 成 的 sig 用 “ ：” 符 合 连 接 的 。 例 如 ： FSdsfDmq7SW2M ： W8d9wgCzMq6+XMQIgs/xBCOgyeY=。
sig 的生成步骤，也就是 auth 签名校验算法如下：
Step 1 构造源串
第 1 步：取出请求body中的参数，以body为key，例如body={“data”: “密文”},生成时间戳以x-hmac-auth-date为key
第 2 步：将第 1 步中排序后的参数(key=value)用&拼接起来，并进行 URL 编码。 请开发者关注：URL 编码注意事项，否则容易导致后面签名不能通过验证。
源串构造示例如下
（1）原始请求信息： 头部：x-hmac-auth-signature = FSdsfDmq7SW2M：M/6fvQXMansoTIKMJISBDtMd330= x-hmac-auth-date = 1400461465910 HTTP 请求方式：GET 请求参数：pf=qzone&format=json&userip=112.90.139.30
（2）下面开始构造源串：
第1步：将除“sig”外的所有参数按 key 进行字典升序排列，排列结果为：format，pf，userip 还有头部的 时间戳：x-hmac-auth-date
第2步：将第 1 步中排序后的参数(key=value)用&拼接起来： format=json&userip=112.90.139.30&x-hmac-auth-date = 1400461465910 然后进行 URL 编码（ 编码时请关注 URL 编码注意事项，否则容易导致后面签名不能通过验证），编码结果为： format%3Djson%26pf%3Dqzone%26userip%3D112.90.139.30%26x-hmac-auth-date%3D2014-04-14T15%3A28%3A03.133%2B08%3A00
Step 2 构造密钥
Appid 和 appkey 都是有通付盾云分配的，在 secretKey 末尾加上一个字节的“&”，例如： 228bf094169a40a3bd188ba37ebe8723&
step 3 生成签名值
使用 HMAC-SHA256 加密算法，使用 Step2 中得到的密钥对 Step1 中得到的源串加密。 然后将加密后的字符串经过 Base64 编码。
得到的签名值结果如下： M/6fvQXMansoTIKMJISBDtMd330=
10.2 URL 编码注意事项
URL 编码注意事项：
URL 编码规则：
签名验证时，要求对字符串中除了“-”、“_”、“.”之外的所有非字母数字字符都替换成百分号(%)后跟两位十六进制数。十六进制数中字母必须为大写。
1）某些系统方法，例如.NET 系统方法 HttpUtility.UrlEncode 会将‘=’编码成‘%3d’，而不是%3D，导致加密签名通不过验证，请开发者注意检查。
2）Java 1.3 和早期版本中，调用 java.net.URLEncoder 下的方法进行 URL 编码时，某些特殊字符并不会被编 码，例如星号(*)。 由于 URL 编码规则中规定了星号(*)必须编码，因此在请求字符串中含星号(*)的情况下如果使用了上述方法，会导致生成的签名不能通过验证。 例如需开发人员手动将星号字符“*”替换为“%2A”，否则将导致加密签名一直通不过验证，请开发者注意检查。
3）某些语言的 urlencode 方法会把“空格”编码为“+”，实际上应该编码为“%20”。这也将生成错误的签名， 导致签名通不过验证。
请开发者注意检查，手动将“+”替换为“%20”。