Request signatures

Obtain the AccessKeyID and SecretAccessKey
Sample signed request
Signing procedure
Signature SDKs

Kingsoft Cloud APIs use Signature Version 4, which is backward compatible with the signature algorithm used by AWS APIs. For security reasons, most Kingsoft Cloud API requests must be signed by using the AccessKey of an account. An AccessKey consists of an AccessKeyID and a SecretAccessKey. We recommend that you use AWS Signature in Postman for testing.

Obtain the AccessKeyID and SecretAccessKey

When you use Kingsoft Cloud APIs for the first time, log in to the Kingsoft Cloud IAM console to obtain the AccessKey of your account.

The AccessKey contains two parts:

AccessKeyID The only representation of the AccessKey, which can be transferred on the Internet.
SecretAccessKey The encryption key for the AccessKey, which is used to encrypt requests and cannot be transferred on the Internet.

Note: The AccessKey is your valuable asset. Keep it safe.

Sample signed request

Original request:

GET HTTP/1.1Content-Type: application/x-www-form-urlencodedHost: cdn.api.ksyun.comX-Amz-Date: 20170621T075413Z

You can add authentication information to the request by using the Authorization header. Despite its name, the Authorization header contains the signature and is used to authenticate the request sender.

The Authorization header contains the following information:

Signature algorithm: AWS4-HMAC-SHA256.
Credential scope: includes your AccessKey.
Signed headers
Signature

Signed request:

GET HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: cdn.api.ksyun.com
X-Amz-Date: 20170621T075413Z
Authorization: AWS4-HMAC-SHA256 Credential=AKLTc0PV6LmgSIu0hncDo6sR4w/20170621/cn-beijing-6/cdn/aws4_request, SignedHeaders=content-type;host;x-amz-date, Signature=cfd799ed7f29203290c6382d1001b56e316561631d7eb120b556c0e4a6e753c0

Signing procedure

1. Create a canonical request

Organize request content, including the host, action, and headers, into a standard format so that it can be used to create a string-to-sign.

Code logic for canonicalizing a request:

$CanonicalRequest = "$HTTPRequestMethod\n$CanonicalURI\n$CanonicalQueryString\n$CanonicalHeaders\n$SignedHeaders" . bin2hex(hash("sha256", $RequestPayload));

Sample request:

GET HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: cdn.api.ksyun.com
X-Amz-Date: 20170621T075413Z

$HTTPRequestMethod: the HTTP request method, for example, GET, PUT, or POST. In this example, the request method is GET.
$CanonicalURI: the canonicalized HTTP absolute path. If the absolute path is empty, set this parameter to a slash (/). Canonicalization is the process of standardizing a URI path based on RFC 3986. Redundant parts are removed, and each part of the path is URI-encoded. In this example, $CanonicalURI is /.
$CanonicalQueryString: the canonicalized query string. If no query string is contained, replace this parameter with a blank line. In this example, $CanonicalQueryString is Action=ListUsers&Version=2015-11-01.

To construct a canonicalized query string, perform the following steps:
a. Sort parameter names in alphabetical order. For example, place a parameter name starting with an upper-case letter F in front of that starting with a lower-case letter b.
b. URI-encode all parameter names and values based on the following rules:
i. Do not URI-encode non-reserved characters defined by RFC 3986, including A to Z, a to z, 0 to 9, hyphens (-), underscores (_), and tildes (~).
ii. Percent-encode all other characters in the %XY format. X and Y are hexadecimal characters, including 0 to 9 and A to F.
c. Construct a canonicalized query string that starts with the first parameter in the sorted list.
d. For each parameter, add the URI-encoded parameter name, an equal sign (=), and the URI-encoded parameter value to the canonicalized query string. If a parameter has no value, use an empty string.
e. Add an ampersand (&) to the end of each parameter value, except the last parameter value in the list.

$CanonicalHeaders: the canonicalized headers. In this example, $CanonicalHeaders is content-type:application/x-www-form-urlencodedhost:cdn.api.ksyun.comx-amz-date:20170621T075413Z.

To canonicalize headers, perform the following steps:
a. Keep at least the Host header.
b. Convert all header names into lower case and remove head and tail spaces. Convert consecutive spaces in header values into a single space.
c. Sort header names in alphabetical order. If one header has multiple values, sort the values and separate them with commas (,). Separate the header name and the values with a colon (: ).
d. Connect the structures constructed in Step c with line breaks (n) to obtain $CanonicalHeaders. Add a line break to the end of the list.

$SignedHeaders: the signed headers. In this example, $SignedHeaders is content-type;host;x-amz-date.
$RequestPayload: the HTTP request body. If the body is empty, use an empty string. In this example, the calculation result is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.
$CanonicalRequest: the calculation result of the procedure. In this example, $CanonicalRequest is GET/Action=ListUsers&Version=2015-11-01content-type:application/x-www-form-urlencodedhost:cdn.api.ksyun.comx-amz-date:20170621T075413Zcontent-type;host;x-amz-datee3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.

2. Create a string-to-sign

Create a string-to-sign by using the canonical request and other information such as the algorithm, request date, credential scope, and the hash digest of the canonical request.

Code logic for creating a string-to-sign:

$StrToSign="AWS4-HMAC-SHA256\n$RequestDateTime\n$CredentialScope\n$HashedCanonicalRequest";

$RequestDateTime: the request time in the format of Ymd\THis\Z, for example, 20170621T075413Z.
$CredentialScope: the credential scope. The parameter value is a string consisting of the date, target region, requested service, and lower-case end string aws4_request, for example, $date/$region/$service/aws4__request. $date: the request time in the format of Ymd, for example, 20170621; $region: 'cn-beijing-6'; ** $service: 'cdn';
$HashedCanonicalRequest: the hash result of $CanonicalRequest by using SHA256.

3. Create a signature key

Perform cryptographic hash operations on the request date, region, and service by using your SecretAccessKey to derive a signature key.

The string-to-sign is obtained from iterative calculation on the SecretAccessKey, request date, region, and service.

Code logic:

$secretKey = 'This is sk';
$kDate = hash_hmac('sha256', 'AWS4$secretKey', $date);
$kRegion = hash_hmac('sha256', $kDate, $region);
$kService = hash_hmac('sha256', $kRegion, $service);
$signKey = hash_hmac('sha256', $kService, 'aws4_request');

$date: the request time in the format of Ymd, for example, 20170621;
$region: 'cn-beijing-6';
$service: 'cdn';

4. Calculate a signature

Perform a cryptographic hash operation on the string-to-sign by using the derivative signature key as the hash key to generate a signature.

Code logic for calculating a signature:

$Signature = hash_hmac('sha256', $StrToSign, $signKey);

5. Add the signature to the request

Add the signature to the Authorization header of the request. The Authorization header is created after the signature is generated and therefore not included in the signed headers. Despite its name, the Authorization header contains the signature and is used to authenticate the request sender.

Code logic:

Authorization: AWS4-HMAC-SHA256Credential=$Accesskey/$CredentialScope, SignedHeaders=$SignedHeaders, Signature=$Signature

$accesskey: the AccessKeyID that matches the SecretAccessKey used in the signing procedure.
$CredentialScope, $SignedHeaders, and $Signature: the same as those described in the preceding section.
Sample Authorization header:

Authorization:AWS4-HMAC-SHA256 Credential=AKIDEXAMPLE/20170621/cn-beijing-6/cdn/aws4_request,SignedHeaders=content-type;host;x-amz-date,Signature=5d672d79c15b13162d9279b0855cfba6789a8edb4c82c400e06b5924a6f2b5d7