概述

V2认证字符串是百度智能云最新的API认证协议方式。基于V2协议，服务可提供更高的请求响应性能，用户也可更大程度保证自己的密钥安全。目前表格服务BTS已经支持v2协议的认证字符串，具体参见BTS API参考。

V2版本认证字符串的生成公式如下：

bce-auth-v2/{accessKeyId}/{date}/{region}/{service}/{signedHeaders}/{signature}

其中：

• accessKeyId： 是Access Key ID，请参看获取AK/SK来获取。

• date：签名的UTC日期，格式为yyyymmdd，例如：20150427。
• region：所请求服务资源所在的区域，小写格式。例如：bj。
• service：所请求的服务名称，小写格式。例如：bos。
• signedHeaders：签名算法中涉及到的HTTP头域列表。HTTP头域名字一律要求小写且头域名字之间用分号（;）分隔，如host;range;x-bce-date。列表按照字典序排列。当signedHeaders为空时表示取默认值。
• signature： 256位签名的十六进制表示，由64个小写字母组成。它由SK(Secret Access Key)和authStringPrefix哈希得到signingKey，再将canonicalRequest以signingKey为key进行哈希摘要生成，具体算法见下。

签名的生成

V2认证签名的计算公式为signature = HMAC-SHA256-HEX(SigningKey,CanonicalRequest)，从公式可以看出，想要获得签名需要得到SigningKey和CanonicalRequest两个参数，接下来讲解如何获取这两个参数。

生成CanonicalRequest

CanonicalRequest的计算公式为： CanonicalRequest = HTTP Method + "\n" + CanonicalURI + "\n" + CanonicalQueryString + "\n" + CanonicalHeaders，

HTTP Method

指HTTP协议中定义的GET、PUT、POST等请求，必须使用全大写的形式。百度智能云API所涉及的HTTP Method有如下五种。

 GET
 POST
 PUT
 DELETE
 HEAD

CanonicalURI

CanonicalURI是对URL中的绝对路径进行编码后的结果，即CanonicalURI = UriEncodeExceptSlash(Path)。要求绝对路径Path必须以“/”开头，不以“/”开头的需要补充上，空路径为“/”。

• 相关举例：

若URL为https://bos.cn-n1.baidubce.com/example/测试，则其URL Path为/example/测试，将之规范化得到CanonicalURI ＝ /example/%E6%B5%8B%E8%AF%95。

CanonicalQueryString

CanonicalQueryString对于URL中的Query String（Query String即URL中“？”后面的“key1 = valve1 & key2 = valve2 ”字符串）进行编码后的结果。

编码步骤如下：

1. 提取URL中的Query String项，即URL中“？”后面的“key1 = valve1 & key2 = valve2 ”字符串
2. 将Query String根据&拆开成若干项，每一项是key=value或者只有key的形式。

3. 对拆开后的每一项进行编码处理，分以下三种情况。

   • 当该项的key是authorization时，直接忽略该项。
   • 当该项只有key时，转换公式为UriEncode(key) + "="的形式。
   • 当该项是key=value的形式时，转换公式为 UriEncode(key) + "=" + UriEncode(value) 的形式。这里value可以是空字符串。
4. 将每一项转换后的字符串按照字典顺序（ASCII码由小到大）排序，并使用& 符号连接起来，生成相应的CanonicalQueryString。

编码示例

获取URL为https://bos.cn-n1.baidubce.com/example?text&text1=测试&text10=test的CanonicalQueryString

1. 提取URL中的Query String，得到 text&text1=测试&text10=test。
2. 根据&对Query String进行拆分，得到text 、text1=测试 、 text10=test三项。

3. 对拆分的每一项进行编码。

   • 对text项进行编码：UriEncode("text") + "="，得到"text="
   • 对text1=测试项进行编码：UriEncode("text1") + "=" + UriEncode("测试")，得到"text1=%E6%B5%8B%E8%AF%95"
   • 对text10=test项进行编码：UriEncode("text10") + "=" + UriEncode("test")，得到"text10=test"
4. 对上面三项编码后的字符串进行（按照ASCII码由小到大）排序，得到结果是text10=test 、text1=%E6%B5%8B%E8%AF%95 、text= ，然后用&连接起来，得到CanonicalQueryString为text10=test&text1=%E6%B5%8B%E8%AF%95&text=。

说明：

1. 函数UriEncode的含义及功能请参考相关解释 。
2. 示例中展示了如何处理只有key的项，非英文的value，以及数字和=进行排序。在实际的BCE API中，因为参数起名是规范的，基本不会遇到这样的排序。正常的排序结果和只按照key进行排序是完全一致的。算法中有这个约束主要是出于定义严密性的考虑。

CanonicalHeaders

CanonicalHeaders是对HTTP请求中的Header部分进行选择性编码的结果。

编码步骤如下：

1. 选择编码的Header。 您可以自行决定哪些Header需要编码。百度智能云API的唯一要求是Host域必须被编码。大多数情况下，我们推荐您对以下Header进行编码：

   • Host
   • Content-Length
   • Content-Type
   • Content-MD5
   • 所有以 x-bce- 开头的Header

   说明

   1. 如果上述Header没有全部出现在您的HTTP请求里面，那么没有出现的部分无需进行编码。如果发送的请求里包含以上header，出现的header必须签名。
   2. 如果您使用上述推荐范围的Header进行编码，那么认证字符串中的 {signedHeaders} 可以直接留空，无需填写。如果您传入了signedHeaders，此时会根据signedHeaders内容进行签名。
   3. 您也可以自己选择想要编码的Header。如果您选择了不在推荐范围内的Header进行编码，或者您的HTTP请求包含了推荐范围内的Header但是您选择不对它进行编码，那么您必须在认证字符串中填写 {signedHeaders} 。填写方法为，把所有在这一阶段进行了编码的Header名字转换成全小写之后按照字典序排列，然后用分号（;）连接。
   4. 选择哪些Header进行编码不会影响API的功能，但是如果选择太少则可能遭到中间人攻击。

2. 对Header进行编码获取CanonicalHeaders，编码步骤如下。

   1. 将Header的名字变成全小写，注意仅改名字。
   2. 将Header的值去掉开头和结尾的空白字符。
   3. 经过上一步之后值为空字符串的Header忽略，其余的转换为 UriEncode(name) + ":" + UriEncode(value) 的形式。
   4. 把上面转换后的所有字符串按照字典序进行排序。
   5. 将排序后的字符串按顺序用\n符号连接起来得到最终的CanonicalHeaders。

说明：
1.UriEncode的含义及功能请参考相关函数说明。

2. 很多发送HTTP请求的第三方库，会添加或者删除你指定的header（例如：某些库会删除content-length:0这个header），如果签名错误，请检查您真实发出的http请求的header，看看是否与签名时的header一样。

编码示例1

该示例演示使用百度智能云推荐范围之外的Header进行编码，此时signedHeaders不能为空（默认值）。在下面的示例中选择对 Date 进行编码，忽略 x-bce-date。

如下是发送请求的Header:

Host: bj.bcebos.com
Date: Mon, 27 Apr 2015 16:23:49 +0800
Content-Type: text/plain
Content-Length: 8
Content-Md5: NFzcPqhviddjRNnSOGo4rw==
x-bce-date: 2015-04-27T08:23:49Z

1. 选择需要编码的Header，然后把所有名字都改为小写。

host: bj.bcebos.com
date: Mon, 27 Apr 2015 16:23:49 +0800
content-type: text/plain
content-length: 8
content-md5: NFzcPqhviddjRNnSOGo4rw==

2. 将Header的值去掉开头和结尾的空白字符。

host:bj.bcebos.com
date:Mon, 27 Apr 2015 16:23:49 +0800
content-type:text/plain
content-length:8
content-md5:NFzcPqhviddjRNnSOGo4rw==

3. 对每个Header进行UriEncode转换。

host:bj.bcebos.com
date:Mon%2C%2027%20Apr%202015%2016%3A23%3A49%20%2B0800
content-type:text%2Fplain
content-length:8
content-md5:NFzcPqhviddjRNnSOGo4rw%3D%3D？

4. 将步骤3中转换后的所有字符串按照字典序进行排序。

content-length:8
content-md5:NFzcPqhviddjRNnSOGo4rw%3D%3D？
content-type:text%2Fplain
date:Mon%2C%2027%20Apr%202015%2016%3A23%3A49%20%2B0800
host:bj.bcebos.com

5. 将排序后的字符串按顺序用\n符号连接起来得到最终结果。

content-length:8
content-md5:NFzcPqhviddjRNnSOGo4rw%3D%3D？
content-type:text%2Fplain
date:Mon%2C%2027%20Apr%202015%2016%3A23%3A49%20%2B0800
host:bj.bcebos.com

同时获得认证字符串的signedHeaders内容应该是content-length;content-md5;content-type;date;host。

编码示例2

该示例演示了CanonicalHeaders的排序和signedHeaders排序不一致的情况。因为BCE API存在允许用户自定义Header的情况，所以这里需要特别注意。

如在BOS的PutObject中允许用户上传自定义meta，为了简明介绍，我们省略大部分Header，假设要编码的Headers如下：

Host: bj.bcebos.com
x-bce-meta-data: my meta data
x-bce-meta-data-tag: description

按照上面的编码步骤，最终得到的CanonicalHeaders是：

host:bj.bcebos.com
x-bce-meta-data-tag:description
x-bce-meta-data:my%20meta%20data

此时获取的signedHeaders是host;x-bce-meta-data;x-bce-meta-data-tag。

可以看出CanonicalHeaders和signedHeaders的排序不一样，这是因为signedHeaders是根据Header的name进行排序的， x-bce-meta-data 放在 x-bce-meta-data-tag 之前。但是在CanonicalHeaders中是按照name和value合成的整个字符串进行排序的，因为在name和value之间还有一个冒号（:），而冒号的ASCII码值要大于连字号（-）的ASCII码值，因此x-bce-meta-data反而放在了x-bce-meta-data-tag之后。

生成SigningKey

SigningKey = HMAC-SHA256-HEX(sk, authStringPrefix)，其中：

• sk为用户的Secret Access Key，可以通过在控制台中进行查询，关于SK的获取方法，请参看获取AK/SK。
• authStringPrefix代表认证字符串的前缀部分，即：bce-auth-v2/{accessKeyId}/{date}/{region}/{service}。

生成Signature及认证字符串

通过上面的计算得到的SigningKey和CanonicalRequest按照下面公式可以得到签名。 Signature = HMAC-SHA256-HEX(SigningKey, CanonicalRequest)

其中：

• HMAC-SHA256-HEX是HMAC SHA256算法函数，具体功能及描述参见相关函数说明。

最后根据公式bce-auth-v2/{accessKeyId}/{date}/{region}/{service}/{signedHeaders}/{signature}获得认证字符串。

相关函数说明

UriEncode()函数参考代码如下：

public static String uri-encode(CharSequence input, boolean encodeSlash) {
    StringBuilder result = new StringBuilder();
        for (int i = 0; i < input.length(); i++) {
            char ch = input.charAt(i);
            if ((ch >= 'A' && ch <= 'Z') || (ch >= 'a' && ch <= 'z') || (ch >= '0' && ch <= '9') || ch == '_' || ch == '-' || ch == '~' || ch == '.') {
                result.append(ch);
            } else if (ch == '/') {
                result.append(encodeSlash ? "%2F" : ch);
            } else {
                result.append(toHexUTF8(ch));
            }
        }
          return result.toString();
}

V2版本与V1版本认证字符串对比

V2认证字符串相比V1版本认证字符串，主要有以下变化：

• 认证字符串的格式调整。V2认证字符串中比V1认证字符串减少了签名时间戳和过期时间，增加了签名日期和生效的服务区域限定。具体格式为： bce-auth-v2/{accessKeyId}/{date}/{region}/{service}/{signedHeaders}/{signature}。
• signingKey生成方式变为： HMAC-SHA256-HEX(sk, "bce-auth-v2/{accessKeyId}/{date}/{region}/{service}")
• 必须签名的头域/请求参数。认证字符串中减少的签名时间戳，要求必须以x-bce-date请求头或QueryString参数形式，计入签名；请求中如通过x-bce-expiration设置过期时间，则也必须计入签名。请求中未指定过期时间的，则默认请求15分钟过期。

相同点： V2中签名的计算过程，同样包含CanonicalRequest、SigningKey、Signature的生成过程，这些与V1版本基本一致。