Облачная платформаAdvanced

App Authentication

Эта статья полезна?

Construct a standard request.
Assemble the request content according to the rules of APIG (API Management), ensuring that the client signature is consistent with that in the backend request.
Create a to-be-signed string using the standard request and other related information.
Calculate a signature using the AK/SK and to-be-signed string.
Add the generated signature to an HTTP request as a header or query parameter.

After receiving the request, APIG performs 1 to 3 to calculate a signature.
Compare the signature generated in 3 with the signature generated in 5. If they are consistent, the request is processed; otherwise, the request is rejected.

Constraints

The body of a signing request in app authentication mode cannot exceed 12 MB.

Step 1: Constructing a Standard Request

To access an API through app authentication, standardize the request content, and then sign the request. The client must follow the same request specifications as APIG 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 example shows how to construct a standard request.

Original request:

GET https://c967a237-cd6c-470e-906f-a8655461897e.apigw.exampleRegion.com/app1?b=2&a=1 HTTP/1.1
Host: c967a237-cd6c-470e-906f-a8655461897e.apigw.exampleRegion.com
X-Sdk-Date: 20191111T093443Z

Specify an HTTP request method (HTTPRequestMethod) and end with a carriage return line feed (CRLF).
For example:
```
GET
```
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

For the URI /app1, the standard URI code is as follows:
```
GET
/app1/
```
A URI must end with a slash (/) for signature calculation. However, the slash is not required when a request is sent.

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

Standard query strings must meet the following requirements:
- 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 a null 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 standard query strings from the first parameter after sorting.
Example

The following example contains two optional parameters a and b.
```
GET
/app1/
a=1&b=2
```

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. When publishing an API in a non-RELEASE environment, you need to specify an environment name.
Notice
The local time on the client must be synchronized with the clock server to avoid a large error in the value of the X-Sdk-Date request header.
APIG checks the time format and compares the time with the time when APIG receives the request. If the time difference exceeds 15 minutes, APIG will reject the request.
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'.
- Lowercase: a function for converting all letters into lowercase letters.
- Trimall: a function for deleting the spaces before and after a value.
- The last message header carries a CRLF. Therefore, an empty line appears because the CanonicalHeaders field also contains a CRLF according to the specifications.
- The message header name must be unique. Otherwise, authentication fails.
Example
```
GET
/app1/
a=1&b=2
host:c967a237-cd6c-470e-906f-a8655461897e.apigw.exampleRegion.com
x-sdk-date:20191111T093443Z
                               //This is a blank line.
```
Notice
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: c967a237-cd6c-470e-906f-a8655461897e.apigw.exampleRegion.com\n
Content-Type: application/json;charset=utf8\n
My-header1: a b c \n
X-Sdk-Date:20191111T093443Z\n
My-Header2: "a b c" \n

A standard header is as follows:

content-type:application/json;charset=utf8\n
host:c967a237-cd6c-470e-906f-a8655461897e.apigw.exampleRegion.com\n
my-header1:a b c\n
my-header2:"a b c"\n
x-sdk-date:20191111T093443Z\n
Add message headers (SignedHeaders) for request signing, and end with a CRLF.
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 example, two message headers host and x-sdk-date are used for signing the request.
```
GET
/app1/
a=1&b=2
host:c967a237-cd6c-470e-906f-a8655461897e.apigw.exampleRegion.com
x-sdk-date:20191111T093443Z

host;x-sdk-date
```
Use the hash function 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: 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.

Example

This example uses GET as an example and leaves the request body empty. After hash processing, the request body (empty string) is as follows:
```
GET
/app1/
a=1&b=2
host:c967a237-cd6c-470e-906f-a8655461897e.apigw.exampleRegion.com
x-sdk-date:20191111T093443Z

host;x-sdk-date
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
```
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 standard request after hash processing:
```
af71c5a7ef45310b8dc05ab15f7da50189ffa81a95cc284379ebaa5eb61155c0
```

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.

StringToSign =
    Algorithm + \n +
    RequestDateTime + \n +
    HashedCanonicalRequest

Parameters in the pseudocode are described as follows:

Algorithm
Signature algorithm. For SHA256, 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
20191111T093443Z
af71c5a7ef45310b8dc05ab15f7da50189ffa81a95cc284379ebaa5eb61155c0

Step 3: Calculating the Signature

Use the AppSecret and created character 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(APP secret, 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
AppSecret	Signature key.
To-be-signed string	Character string to be signed.

If the AppSecret is FWTh***XMD8, the calculated signature is as follows:

5ac0b7c4035112cd840397e12d10cd1ca065328d03a6242d5cbfbbd63659c011

Step 4: Adding the Signature to the Request Header

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

The pseudocode is as follows:

Authorization header creation pseudocode:
Authorization: algorithm Access=APP key, SignedHeaders=SignedHeaders, Signature=signature

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

The signed headers are as follows:

Authorization: SDK-HMAC-SHA256 Access=FM9RLCN************NAXISK, SignedHeaders=host;x-sdk-date, Signature=5ac0b7c4035112cd840397e12d10cd1ca065328d03a6242d5cbfbbd63659c011

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 backend service for processing.

Parent topic: Calling APIs Through App Authentication

Поддержка Юридические документы