生成V2认证字符串 - 相关参考Reference | 百度智能云文档


本站和网页 https://cloud.baidu.com/doc/Reference/s/hjwvz1y4f 的作者无关,不对其内容负责。快照谨为网络故障时之索引,不代表被搜索网站的即时页面。

生成V2认证字符串 - 相关参考Reference | 百度智能云文档
百度智能云
最新活动产品解决方案企业服务云市场合作与生态开发者服务与支持了解智能云
备案文档管理控制台
This app works best with JavaScript enabled.文档中心API中心SDK中心视频中心生成V2认证字符串相关参考 Reference功能发布记录企业组织产品介绍企业组织vs多用户访问控制创建企业组织邀请-新建账户账户授权组织单元资源管理财务管理账户联合认证(SSO)退出组织常见问题API参考简介通用说明企业组织管理接口账户管理接口邀请管理接口单元管理接口策略管理接口数据类型证书管理简介证书和私钥格式转换上传证书管理证书多用户访问控制证书替换第三方机构创建证书API参考JAVA-SDKPython-SDK常见问题获取AKSK简介如何获取AKSK鉴权认证机制简介签名流程生成认证字符串生成V2认证字符串在Header中包含认证字符串在URL中包含认证字符串Sample-Code常见签名认证错误排查错误码区域选择说明区域可用区SDK入门指南Java-SDK入门指南PHP-SDK入门指南Python-SDK帮助指南API SDKJava SDK术语表ABCDEFGHIJKLMNOPQRSTVWXYZ文档有奖反馈活动所有文档相关参考 Reference功能发布记录企业组织产品介绍企业组织vs多用户访问控制创建企业组织邀请-新建账户账户授权组织单元资源管理财务管理账户联合认证(SSO)退出组织常见问题API参考简介通用说明企业组织管理接口账户管理接口邀请管理接口单元管理接口策略管理接口数据类型证书管理简介证书和私钥格式转换上传证书管理证书多用户访问控制证书替换第三方机构创建证书API参考JAVA-SDKPython-SDK常见问题获取AKSK简介如何获取AKSK鉴权认证机制简介签名流程生成认证字符串生成V2认证字符串在Header中包含认证字符串在URL中包含认证字符串Sample-Code常见签名认证错误排查错误码区域选择说明区域可用区SDK入门指南Java-SDK入门指南PHP-SDK入门指南Python-SDK帮助指南API SDKJava SDK术语表ABCDEFGHIJKLMNOPQRSTVWXYZ文档有奖反馈活动文档中心>相关参考Reference>鉴权认证机制>生成V2认证字符串本页目录概述签名的生成生成CanonicalRequestHTTP MethodCanonicalURICanonicalQueryStringCanonicalHeaders生成SigningKey生成Signature及认证字符串相关函数说明V2版本与V1版本认证字符串对比生成V2认证字符串更新时间:2020-02-16概述
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 ”字符串)进行编码后的结果。
编码步骤如下:
提取URL中的Query String项,即URL中“?”后面的“key1 = valve1 & key2 = valve2 ”字符串
将Query String根据&拆开成若干项,每一项是key=value或者只有key的形式。
对拆开后的每一项进行编码处理,分以下三种情况。
当该项的key是authorization时,直接忽略该项。
当该项只有key时,转换公式为UriEncode(key) + "="的形式。
当该项是key=value的形式时,转换公式为 UriEncode(key) + "=" + UriEncode(value) 的形式。这里value可以是空字符串。
将每一项转换后的字符串按照字典顺序(ASCII码由小到大)排序,并使用& 符号连接起来,生成相应的CanonicalQueryString。
编码示例
获取URL为https://bos.cn-n1.baidubce.com/example?text&text1=测试&text10=test的CanonicalQueryString
提取URL中的Query String,得到 text&text1=测试&text10=test。
根据&对Query String进行拆分,得到text 、text1=测试 、 text10=test三项。
对拆分的每一项进行编码。
对text项进行编码:UriEncode("text") + "=",得到"text="
对text1=测试项进行编码:UriEncode("text1") + "=" + UriEncode("测试"),得到"text1=%E6%B5%8B%E8%AF%95"
对text10=test项进行编码:UriEncode("text10") + "=" + UriEncode("test"),得到"text10=test"
对上面三项编码后的字符串进行(按照ASCII码由小到大)排序,得到结果是text10=test 、text1=%E6%B5%8B%E8%AF%95 、text= ,然后用&连接起来,得到CanonicalQueryString为text10=test&text1=%E6%B5%8B%E8%AF%95&text=。
说明:
函数UriEncode的含义及功能请参考相关解释 。
示例中展示了如何处理只有key的项,非英文的value,以及数字和=进行排序。在实际的BCE API中,因为参数起名是规范的,基本不会遇到这样的排序。正常的排序结果和只按照key进行排序是完全一致的。算法中有这个约束主要是出于定义严密性的考虑。
CanonicalHeaders
CanonicalHeaders是对HTTP请求中的Header部分进行选择性编码的结果。
编码步骤如下:
选择编码的Header。
您可以自行决定哪些Header需要编码。百度智能云API的唯一要求是Host域必须被编码。大多数情况下,我们推荐您对以下Header进行编码:
Host
Content-Length
Content-Type
Content-MD5
所有以 x-bce- 开头的Header
说明
如果上述Header没有全部出现在您的HTTP请求里面,那么没有出现的部分无需进行编码。如果发送的请求里包含以上header,出现的header必须签名。
如果您使用上述推荐范围的Header进行编码,那么认证字符串中的 {signedHeaders} 可以直接留空,无需填写。如果您传入了signedHeaders,此时会根据signedHeaders内容进行签名。
您也可以自己选择想要编码的Header。如果您选择了不在推荐范围内的Header进行编码,或者您的HTTP请求包含了推荐范围内的Header但是您选择不对它进行编码,那么您必须在认证字符串中填写 {signedHeaders} 。填写方法为,把所有在这一阶段进行了编码的Header名字转换成全小写之后按照字典序排列,然后用分号(;)连接。
选择哪些Header进行编码不会影响API的功能,但是如果选择太少则可能遭到中间人攻击。
对Header进行编码获取CanonicalHeaders,编码步骤如下。
将Header的名字变成全小写,注意仅改名字。
将Header的值去掉开头和结尾的空白字符。
经过上一步之后值为空字符串的Header忽略,其余的转换为 UriEncode(name) + ":" + UriEncode(value) 的形式。
把上面转换后的所有字符串按照字典序进行排序。
将排序后的字符串按顺序用\n符号连接起来得到最终的CanonicalHeaders。
说明:
1.UriEncode的含义及功能请参考相关函数说明。
很多发送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
选择需要编码的Header,然后把所有名字都改为小写。
host: bj.bcebos.com
date: Mon, 27 Apr 2015 16:23:49 +0800
content-type: text/plain
content-length: 8
content-md5: NFzcPqhviddjRNnSOGo4rw==
将Header的值去掉开头和结尾的空白字符。
host:bj.bcebos.com
date:Mon, 27 Apr 2015 16:23:49 +0800
content-type:text/plain
content-length:8
content-md5:NFzcPqhviddjRNnSOGo4rw==
对每个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?
将步骤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
将排序后的字符串按顺序用\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}获得认证字符串。
相关函数说明
函数名
功能描述
HMAC-SHA256-HEX()
调用HMAC SHA256算法,根据开发者提供的密钥(key)和密文(message)输出密文摘要,并把结果转换为小写形式的十六进制字符串。
Lowercase()
将字符串全部变成小写。
Trim()
去掉字符串开头和结尾的空白字符。
UriEncode()
RFC 3986规定,"URI非保留字符"包括以下字符:字母(A-Z,a-z)、数字(0-9)、连字号(-)、点号(.)、下划线(_)、波浪线(~),算法实现如下: 1. 将字符串转换成UTF-8编码的字节流 2. 保留所有“URI非保留字符”原样不变 3. 对其余字节做一次RFC 3986中规定的百分号编码(Percent-encoding),即一个“%”后面跟着两个表示该字节值的十六进制字母,字母一律采用大写形式。
UriEncodeExceptSlash()
与UriEncode() 类似,区别是斜杠(/)不做编码。一个简单的实现方式是先调用UriEncode(),然后把结果中所有的%2F都替换为/
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版本基本一致。 上一篇生成认证字符串下一篇在Header中包含认证字符串本篇文档内容是否对您有帮助?有帮助没帮助有奖抓虫文档反馈
关于智能云百度智能云2.0云智技术论坛行业白皮书智能云公告最新资讯客户案例服务案例方案手册产品手册热门产品云服务器对象存储数据可视化文字识别语音识别图像识别域名服务BML全功能AI开发平台曦灵·数字人直播平台内容分发网络CDN负载均衡智能解决方案智慧城市智能制造智慧能源智慧水务智慧金融智慧媒体智慧电信智慧教育企业上云快速入口控制台备案帮助产品促销企业服务云市场合作伙伴中心支持计划专家服务帮助文档售前服务咨询支持热线(4008-777-818)技术工单建议反馈违规举报关于百度智能云云智一体2.0AI体验中心最新资讯产品动态市场活动客户案例行业解读公告通知联系我们服务与支持文档中心入门指南视频中心培训与认证企业支持计划专家服务重大保障服务自助服务智能助手账户管理管理控制台实名认证域名管理备案管理个人中心财务与订单发票申请消息中心我的工单快速入口成为合作伙伴云市场最新活动企业服务开发者社区SDK中心API平台开发者沙龙飞桨大赛实用工具短网址域名信息查询SSL证书文字识别语音识别图片识别卡证识别文档翻译图片翻译售前咨询热线4008-777-818转1售前在线咨询售后智能助手技术工单违规举报头部7*24小时服务企业支持计划电子化备案建议反馈热门推荐云服务器云磁盘商标注册文字识别弹性公网IP海外CDN数据传输服务内容分发网络人脸与人体识别弹性裸金属服务器SSL证书域名服务容器引擎专线接入音视频直播智能推荐引擎GPU云服务器Elasticsearch云数据库HBase爱速搭低代码平台智能边缘私有网络应用引擎文件存储智能云解析MapReduce简单消息服务轻量应用服务器智能视联网平台云数据库GaiaDB-X日志服务消息服务负载均衡对象存储云虚拟主机数据仓库Palo容器镜像服务云数据库DocDB超级链BaaS平台云原生微服务应用平台解决方案智慧城市智慧金融智能制造智慧能源智慧媒体智慧水务智能图云企业上云区块链物联网热门搜索数字人云手机直播平台数据分析边缘计算域名解析数据可视化自然语言处理数据采集虚拟主机快速链接百度搜索百度大脑百度VR百度AI市场百度统计百度指数百度云加速百度阿波罗百度地图慧眼百度翻译开放平台百度营销百度如流百度安全百度短网址百度有驾百度联盟百度超级链百度数据众包百度网盘企业版百度搜索资源平台