1 认证前准备

• 调用区域的网关域名

• 请求URL（分组path与API path）

• 请求方法

• 提供有效的AppKey、AppSecret才能生成认证签名

在“应用管理”中添加一个APP，并将APP绑定/订阅API，就可以使用APP对应的AppKey和AppSecert访问该API。可在应用详细信息中查看AppKey和AppSecret。

2 APP认证工作原理

• 构造规范请求

• 使用规范请求和其他信息创建待签字符串

• 使用AppKey与AppSecret和待签字符串生成签名

• 将签名与其他信息作为请求消息添加到HTTP请求头中

• 网关收到请求后执行相应操作计算签名

• 将签名进行比较如果匹配则处理请求，否则将拒绝请求

2.1 构造规范请求

① HTTP请求规范代码：

CanonicalRequest =
    HTTPRequestMethod + '\n' +
    CanonicalURI + '\n' +
    CanonicalQueryString + '\n' +
    CanonicalHeaders + '\n' +
    SignedHeaders + '\n' +
    HexEncode(Hash(RequestPayload))

② 假设原始请求为：

GET https://www.kcgw.com/service/api?a=1  HTTP/1.1
X-Api-TimeStamp: 123456
X-Api-AppKey: 1615343734

③ 构造HTTP请求方法（HTTPRequestMethod），以换行符结束。

HTTP请求方法，如GET、PUT、POST等。请求方法示例：

GET

④ 规范URI参数: CanonicalURI 根据RFC 3986标准化URI路径，移除冗余和相对路径部分，路径中每个部分必须为URI编码。如果URI路径不以“/”结尾，则在尾部添加“/”。

则示例的规范URI参数为：

/service/api/

⑤ 规范查询字符串: CanonicalQueryString 根据以下规则对每个参数名和值进行URI编码，如果没有请求参数则为空字符串，即规范后的请求为空行。

则示例的规范查询字符串为 a=1

• 请勿对RFC 3986定义的任何非预留字符进行URI编码，这些字符包括：A-Z、a-z、0-9、-、_、.和~。

• 使用%XY对所有非预留字符进行百分比编码，其中X和Y为十六进制字符（0-9和A-F）。例如，空格字符必须编码为%20，扩展UTF-8字符必须采用“%XY%ZA%BC”格式。

• 对于每个参数，追加“URI编码的参数名称=URI编码的参数值”。如果没有参数值，则以空字符串代替，但不能省略“=”。

• 按照字符代码以升序顺序对参数名进行排序。例如，以大写字母F开头的参数名排在以小写字母b开头的参数名之前。

• 以排序后的第一个参数名开始，构造规范查询字符串。

举例：

a=1

⑥ 添加规范消息头: CanonicalHeaders

格式：

CanonicalHeaders由多个请求消息头共同组成，CanonicalHeadersEntry0 + CanonicalHeadersEntry1 + ...，其中每个请求消息头（CanonicalHeadersEntry ）的格式为Lowercase(HeaderName) + ':' + Trimall(HeaderValue) + '\n'

则示例的规范消息头为：

• Lowercase表示将所有字符转换为小写字母的函数。

• Trimall表示删除值前后的多余空格的函数。

• 最后一个请求消息头也会携带一个换行符。叠加规范中CanonicalHeaders自身携带的换行符，因此会出现一个空行。

GET\n
/service/api/\n
a=1\n
content-type:application/json\n
x-api-timestamp:123456\n\n

⑦ 添加用于签名的消息头声明（SignedHeaders），以换行符结束。

释义：

用于签名的请求消息头列表。通过添加此消息头，向API网关告知请求中哪些消息头是签名过程的一部分，以及在验证请求时API网关可以忽略哪些消息头。X-Sdk-date必须作为已签名的消息头。

格式：

SignedHeaders = Lowercase(HeaderName0) + ';' + Lowercase(HeaderName1) + ";" + ...

已签名的消息头需要满足以下要求：将已签名的消息头名称转换为小写形式，按照字符代码对消息头进行排序，并使用“;”来分隔多个消息头。

Lowercase表示将所有字符转换为小写字母。

举例：

GET\n
/service/api/\n
a=1\n
content-type:application/json\n
x-api-timestamp:123456\n\n
x-api-timestamp\n

⑧ RequestPayload 使用SHA 256哈希函数以基于HTTP或HTTPS请求正文中的body体（RequestPayload），创建哈希值。

• 计算RequestPayload的哈希值时，对于“RequestPayload==null”的场景，直接使用空字符串""来计算。

则示例空字符的RequestPayload为：

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

⑨ 对构造好的规范请求进行哈希处理，算法与对RequestPayload哈希处理的算法相同。经过哈希处理的规范请求必须以小写十六进制字符串形式表示。

CanonicalRequest  = 
“GET”  + \n
“/service/api” +  \n
“a=1” +  \n
“x-api-timestamp: 123456”  +  \n\n
“x-api-timestamp” + \n
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

算法伪代码：Lowercase(HexEncode(Hash.SHA256(CanonicalRequest)))

2.2 生成签名字符串

使用HMAC-SHA256算法对上一步中获得的签名原文进行加密签名以16进制格式输出，然后将生成的签名串使用Base64编码，即可获得最终的签名串。

2.3 将签名等信息加入请求头部

必须携带的header:

• X-Api-AppKey：应用AppKey

• X-Api-TimeStamp：当前时间戳

• X-Api-SignHeaders: 参与签名的header，最少携带X-Api-TimeStamp

• X-Api-Signature：规范请求字符串与AppSecret Hmac256后转base64