Help Center/ API Request Signing Guide/ Developer Guide/ API Signature Authentication Principles/ API Signature Authentication Mechanism
Updated on 2026-02-09 GMT+08:00
View PDF

API Signature Authentication Mechanism

If the preceding signing examples do not contain the programming language you use, sign requests according to the API signature authentication mechanism.

Step 1: Constructing 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.

The pseudocode of standard HTTP requests is as follows: 
CanonicalRequest =
      HTTPRequestMethod + '\n' + //HTTP request method
      CanonicalURI + '\n' + //Canonical URI
      CanonicalQueryString + '\n' + //Canonical query string
      CanonicalHeaders + '\n' + //Canonical message header
      SignedHeaders + '\n' + //Signed message header
      HexEncode(Hash(RequestPayload)) //Calculate the hash value of RequestPayload.
  • HTTPRequestMethod

    HTTP request methods, such as GET, PUT, and POST, followed by a newline character.

  • CanonicalURI

    Path of the requested resource, which is the URI code of the absolute path. The value ends with a newline character.

    According to RFC 3986, each part of a valid URI except the redundant and relative paths must be URI-encoded. A URI must end with a slash (/) for signature calculation. However, the slash is not required when a request is sent.

  • CanonicalQueryString

    Query strings. The value ends with a newline character. If no query strings are configured, an empty string is used.

    Pay attention to the following to ensure valid 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.
  • CanonicalHeaders

    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. The value ends with a newline character.

    • The local time on the client must be synchronized with the clock server to avoid a large offset in the value of the X-Sdk-Date request header.
    • API Gateway checks the time format and compares the time with the time when API Gateway receives the request. If the time difference exceeds 15 minutes, API Gateway will reject the request.
    CanonicalHeaders consists of multiple message headers, for example, CanonicalHeadersEntry0 + CanonicalHeadersEntry1 + .... Each message header (CanonicalHeadersEntry) is in the format of Lowercase(HeaderName) + ':' + Trimall(HeaderValue) + '\n'.
    • 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 newline character. Therefore, an empty line appears because the CanonicalHeaders field also contains a newline character according to the specifications.
    • 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
  • SignedHeaders

    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.

    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.
  • RequestPayload

    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.

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

Step 2: Creating 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.

The following is the pseudocode for creating a to-be-signed string: 
StringToSign =
    Algorithm + \n +
    RequestDateTime + \n +
    HashedCanonicalRequest
  • Algorithm

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

  • RequestDateTime

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

  • HashedCanonicalRequest

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

    The pseudocode of the algorithm is as follows:

    Lowercase(HexEncode(Hash.SHA256(CanonicalRequest)))

Step 3: Calculating 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(Secret Access Key, string to sign))
  • HexEncode

    HexEncode indicates the hexadecimal conversion.

  • HMAC

    HMAC indicates the key-related hash operation.

  • Secret Access Key

    Secret Access Key indicates the signature key SK.

  • string to sign

    string to sign is the string created in Step 2: Creating a To-Be-Signed String.

Step 4: Adding the Signature to the Request Header

After calculating the signature, add the signature to the HTTP message header in Authorization for identity authentication.

The pseudocode for creating the Authorization header is as follows:

Authorization: algorithm Access=Access key, SignedHeaders=SignedHeaders, Signature=signature

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

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.