Help Center> > Developer Guide >AK/SK Authentication

AK/SK Authentication

The AK/SK authentication process at the client end is as follows:

  1. Construct a standard request.

    Assemble the request content according to the rules of API Gateway, ensuring that the client signature is consistent with that in the backend request.

  2. Create a to-be-signed string using the standard request and other related information.
  3. Calculate a signature using the AK/SK and to-be-signed string.
  4. Add the generated signature to an HTTP request as a header or query parameter.

The following describes the process in detail.

Step 1: Construct a Standard Request

To access an API through AK/SK authentication, standardize the request content, and then sign the request. The client must follow the same request specifications as API Gateway so that each HTTP request can obtain the same signing result from the frontend and backend to complete identity authentication.

The pseudocode of standard HTTP requests is as follows:
CanonicalRequest =
      HTTPRequestMethod + '\n' +
      CanonicalURI + '\n' +
      CanonicalQueryString + '\n' +
      CanonicalHeaders + '\n' +
      SignedHeaders + '\n' +
      HexEncode(Hash(RequestPayload))

The following procedure uses the Virtual Private Cloud (VPC) list query API as an example to describe how to construct a standard request.

Original request:

GET https://service.region.example.com/v1/77b6a44cba5143ab91d13ab9a8ff44fd/vpcs?limit=2&marker=13551d6b-755d-4757-b956-536f674975c0 HTTP/1.1
Host: service.region.example.com
X-Sdk-Date: 20190329T074551Z
  1. Specify an HTTP request method (HTTPRequestMethod) and end with a carriage return line feed (CRLF).

    Specify GET, PUT, POST, or another request method. For example:

    GET

  2. Add a standard URI (CanonicalURI) and end with a CRLF.

    Description

    Path of the requested resource, which is the URI code of the absolute path.

    Format

    According to RFC 3986, each part of a standard URI except the redundant and relative paths must be URI-encoded. If a URI does not end with a slash (/), add a slash at its end.

    Example

    See the URI of each API in the API Reference of the corresponding cloud service. For example, the standard URI code of the VPC list query API (/v1/{project_id}/vpcs) is as follows:

    GET
    /v1/77b6a44cba5143ab91d13ab9a8ff44fd/vpcs/
    NOTE:

    During signature calculation, the URI must end with a slash (/). When a request is sent, the URI does not need to end with a slash (/).

  3. Add a standard query string (CanonicalQueryString) and end with a CRLF.

    Description

    Query parameters. If no query parameters are configured, the query string is an empty string.

    Format

    Pay attention to the following to ensure standard query strings:

    • Perform URI encoding on each parameter and value according to the following rules:
      • Do not perform URI encoding on any non-reserved characters defined in RFC 3986, including A–Z, a–z, 0–9, hyphen (-), underscore (_), period (.), and tilde (~).
      • Use %XY to perform percent encoding on all non-reserved characters. X and Y indicate hexadecimal characters (0–9 and A–F). For example, the space character must be encoded as %20, and an extended UTF-8 character must be encoded in the "%XY%ZA%BC" format.
    • Add "URI-encoded parameter name=URI-encoded parameter value" to each parameter. If no value is specified, use an empty string instead. The equal sign (=) is required.
      For example, in the following string that contains two parameters, the value of parameter parm2 is null.
      parm1=value1&parm2=
    • Sort the parameters in alphabetically ascending order. For example, a parameter starting with uppercase letter F precedes another parameter starting with lowercase letter b.
    • Construct a standard query string from the first parameter after sorting.

    Example

    The URI of the VPC list query API contains two optional parameters: limit and marker. limit indicates the number of records displayed on each page, and marker indicates the start VPC ID for pagination query.
    GET
    /v1/77b6a44cba5143ab91d13ab9a8ff44fd/vpcs/
    limit=2&marker=13551d6b-755d-4757-b956-536f674975c0

  4. Add standard headers (CanonicalHeaders) and end with a CRLF.

    Description

    List of standard request headers, including all HTTP message headers in the to-be-signed request. The X-Sdk-Date header must be included to verify the signing time, which is in the UTC time format YYYYMMDDTHHMMSSZ as specified in ISO 8601.

    Format

    CanonicalHeaders consists of multiple message headers, for example, CanonicalHeadersEntry0 + CanonicalHeadersEntry1 + .... Each message header (CanonicalHeadersEntry) is in the format of Lowercase(HeaderName) + ':' + Trimall(HeaderValue) + '\n'.

    NOTE:
    • Lowercase is a function for converting all letters into lowercase letters.
    • Trimall is a function for deleting the spaces before and after a value.
    • The last message header carries a CALF. Therefore, an empty line appears because the CanonicalHeaders field also contains a CALF according to the specifications.

    Example

    Requests for calling the VPC list query API need to contain the X-Sdk-Date, Host (cloud service endpoint), and Content-Type headers.
    GET
    /v1/77b6a44cba5143ab91d13ab9a8ff44fd/vpcs/
    limit=2&marker=13551d6b-755d-4757-b956-536f674975c0
    content-type:application/json
    host:service.region.example.com
    x-sdk-date:20190329T074551Z

    Standard message headers must meet the following requirements:

    • All letters in a header are converted to lowercase letters, and all spaces before and after the header are deleted.
    • All headers are sorted in alphabetically ascending order.

    For example, the original headers are as follows:

    Host: service.region.example.com\n
    Content-Type: application/json;charset=utf8\n
    My-header1:    a   b   c  \n
    X-Sdk-Date:20190318T094751Z\n
    My-Header2:    "x   y   \n

    The message header names are converted into lowercase letters, the message headers are sorted in alphabetical order, and spaces before and after the header values are deleted. The standardized message headers are as follows:

    content-type:application/json;charset=utf8\n
    host:service.region.example.com\n
    my-header1:a   b   c\n
    my-header2:"x   y\n
    x-sdk-date:20190318T094751Z\n
    

  5. Add message headers (SignedHeaders) for request signing, and end with a CALF.

    Description

    List of message headers used for request signing. This step is to determine which headers are used for signing the request and which headers can be ignored during request verification. The X-Sdk-date header must be included.

    Format

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

    Letters in the message headers are converted to lowercase letters. All headers are sorted alphabetically and separated with commas.

    Lowercase is a function for converting all letters into lowercase letters.

    Example

    In the following request, the Content-Type, Host, and X-Sdk-Date headers are used for request signing.
    GET
    /v1/77b6a44cba5143ab91d13ab9a8ff44fd/vpcs/
    limit=2&marker=13551d6b-755d-4757-b956-536f674975c0
    content-type:application/json
    host:service.region.example.com
    x-sdk-date:20190329T074551Z
    
    content-type;host;x-sdk-date

  6. Use a hash function, such as SHA-256, to create a hash value based on the body (RequestPayload) of the HTTP or HTTPS request.

    Description

    Request message body. The message body needs two layers of conversion (HexEncode(Hash(RequestPayload))). Hash is a function for generating message digest. Currently, SHA-256 is supported. HexEncode is the Base16 encoding function for returning a digest consisting of lowercase letters. For example, HexEncode("m") returns 6d instead of 6D. Each byte you enter is expressed as two hexadecimal characters.

    NOTE:

    If RequestPayload is null, the null value is used for calculating a hash value.

    Example

    For a request with the GET method and an empty body, the body (empty string) after hash processing is as follows:

    GET
    /v1/77b6a44cba5143ab91d13ab9a8ff44fd/vpcs/
    limit=2&marker=13551d6b-755d-4757-b956-536f674975c0
    content-type:application/json
    host:service.region.example.com
    x-sdk-date:20190329T074551Z
    
    content-type;host;x-sdk-date
    e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

    A standard request is constructed.

  7. Perform hash processing on the standard request in the same way as that on the RequestPayload. After hash processing, the standard request is expressed with lowercase hexadecimal strings.

    Algorithm pseudocode: Lowercase(HexEncode(Hash.SHA256(CanonicalRequest)))

    Example of the standard request after hash processing:

    9f5ad2be0a6921a5ea888f13f3e1a750da9c45e6978812ffafc140bdecba1174

Step 2: Create a To-Be-Signed String

After a standard HTTP request is constructed and the request hash value is obtained, create a to-be-signed string by combining them with the signature algorithm and signing time.
StringToSign =
    Algorithm + \n +
    RequestDateTime + \n +
    HashedCanonicalRequest

Parameters in the pseudocode are described as follows:

  • Algorithm

    Signature algorithm. For SHA-256, the value is SDK-HMAC-SHA256.

  • RequestDateTime

    Request timestamp, which is the same as X-Sdk-Date in the request header. The format is YYYYMMDDTHHMMSSZ.

  • HashedCanonicalRequest

    Standard request generated after hash processing.

In this example, the following to-be-signed string is obtained:
SDK-HMAC-SHA256
20190329T074551Z
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Step 3: Calculate the Signature

Use the SK and to-be-signed string as the input of the encryption hash function, and convert the calculated binary signature into a hexadecimal expression.

The pseudocode is as follows:

signature = HexEncode(HMAC(Access Secret Key, string to sign))

HMAC indicates hash calculation, and HexEncode indicates hexadecimal conversion. Table 1 describes the parameters in the pseudocode.

Table 1 Parameter description

Parameter

Description

Access Secret Key

Signature key

string to sign

Character string to be signed

If the AK is MFyfvK41ba2giqM7Uio6PznpdUKGpownRZlmVmHc, the calculated signature is as follows:

9f5ad2be0a6921a5ea888f13f3e1a750da9c45e6978812ffafc140bdecba1174

Step 4: Add the Signature to the Request Header

Add the signature to the Authorization HTTP header. The Authorization header is used for identity authentication and not included in the SignedHeaders.

The pseudocode is as follows:

Pseudocode for Authorization header creation:
Authorization: algorithm Access=Access key, SignedHeaders=SignedHeaders, Signature=signature

There is no comma but a space before the algorithm and Access. SignedHeaders and Signature must be separated with commas.

The signed headers are as follows:

SDK-HMAC-SHA256 Access=QTWAOYTTINDUT2QVKYUC, SignedHeaders=content-type;host;x-sdk-date, Signature=d66f6a6c536e984129e13a4060f465225909fd126d212cb25e9e292346aae036

The signed headers are added to the HTTP request for identity authentication. If the identity authentication is successful, the request is sent to the corresponding cloud service for processing.

The complete request that contains the signature information is as follows:

GET /v1/77b6a44cba5143ab91d13ab9a8ff44fd/vpcs?limit=2& marker=13551d6b-755d-4757-b956-536f674975c0 HTTP/1.1
Host: service.region.example.com
Content-Type: application/json
x-sdk-date: 20190329T074551Z
Authorization: SDK-HMAC-SHA256 Access=QTWAOYTTINDUT2QVKYUC, SignedHeaders=content-type;host;x-sdk-date, Signature=d66f6a6c536e984129e13a4060f465225909fd126d212cb25e9e292346aae036

Example request for calling an API with cURL:

curl -X GET "https://service.region.example.com/v1/77b6a44cba5143ab91d13ab9a8ff44fd/vpcs?limit=2&marker=13551d6b-755d-4757-b956-536f674975c0" -H "Content-Type: application/json" -H "X-Sdk-Date: 20190329T074551Z" -H "host: service.region.example.com" -H "Authorization: SDK-HMAC-SHA256 Access=QTWAOYTTINDUT2QVKYUC, SignedHeaders=content-type;host;x-sdk-date, Signature=d66f6a6c536e984129e13a4060f465225909fd126d212cb25e9e292346aae036" -d $''