Compute
Elastic Cloud Server
Huawei Cloud Flexus
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Networking
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Management & Governance
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
OneAccess
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
IAM Identity Center
Cloud Operations Center
Resource Governance Center
Migration
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Analytics
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
Data Lake Factory
DataArts Lake Formation
IoT
IoT Device Access
Others
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Security & Compliance
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Anti-DDoS Service
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Edge Security
Situation Awareness
Managed Threat Detection
Blockchain
Blockchain Service
Web3 Node Engine Service
Media Services
Media Processing Center
Video On Demand
Live
SparkRTC
MetaStudio
Storage
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Storage Disaster Recovery Service
Scalable File Service Turbo
Scalable File Service
Volume Backup Service
Cloud Server Backup Service
Data Express Service
Dedicated Distributed Storage Service
Containers
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Databases
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
Multi-Site High Availability Service
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Business Applications
Workspace
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Video Intelligent Analysis Service
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Content Delivery & Edge Computing
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Intelligent EdgeCloud
Solutions
SAP Cloud
High Performance Computing
Developer Services
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
CodeArts Repo
Cloud Application Engine
MacroVerse aPaaS
KooMessage
KooPhone
KooDrive

Other Programming Languages

Updated on 2024-04-29 GMT+08:00

App Authentication Principle

  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.
  1. After receiving the request, API Gateway performs 1 to 3 to calculate a signature.
  2. The new signature generated in 3 is compared with the signature generated in 5. If they are consistent, the request is processed; otherwise, the request is rejected.
NOTE:

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 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 example shows how to construct a standard request.

Original request:

GET https://{apig-endpoint}/app1?b=2&a=1 HTTP/1.1
Host: {apig-endpoint}
X-Sdk-Date: 20180330T123600Z
  1. Specify an HTTP request method (HTTPRequestMethod) and end with a carriage return line feed (CRLF).

    Specify GET, PUT, POST, or another request method. Example of a request method:

    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

    For the URI /app1, the standard URI code is as follows:

    GET
    /app1/
    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 (/).

  1. 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
  1. 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.

    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 CRLF. Therefore, an empty line appears because the CanonicalHeaders field also contains a CRLF according to the specifications.

    Example

    GET
    /app1/
    a=1&b=2
    host:{apig-endpoint}
    x-sdk-date:20180330T123600Z
    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 is deleted.
    • All headers are sorted in alphabetically ascending order.

    For example, the original headers are as follows:

    Host: {apig-endpoint}\n
    Content-Type: application/json;charset=utf8\n
    My-header1:    a   b   c  \n
    X-Sdk-Date:20180330T123600Z\n
    My-Header2:    "a   b   c"  \n

    A standard header is as follows:

    content-type:application/json;charset=utf8\n
    host:{apig-endpoint}\n
    my-header1:a   b   c\n
    my-header2:"a   b   c"\n
    x-sdk-date:20180330T123600Z\n
  2. 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:{apig-endpoint}
    x-sdk-date:20180330T123600Z
    
    host;x-sdk-date
  3. 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: 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
    /app1/
    a=1&b=2
    host:{apig-endpoint}
    x-sdk-date:20180330T123600Z
    
    host;x-sdk-date
    e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
  4. 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:

    4bd8e1afe76738a332ecff075321623fb90ebb181fe79ec3e23dcb081ef15906

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
20180330T123600Z
4bd8e1afe76738a332ecff075321623fb90ebb181fe79ec3e23dcb081ef15906

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. Coded or plaintext AK and SK pose significant security risks. To ensure security, encrypt your AK and SK, store them in configuration files or environment variables, and decrypt them when needed.

To-be-signed string

Character string to be signed.

Assuming that the AppSecret is 12345678-1234-1234-1234-123456781234, a signature similar to the following will be calculated:

cb978df7c06ac242bab1d1b39d697ef7df4806664a6e09d5f5308a6b25043ea2

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=071fe245-9cf6-4d75-822d-c29945a1e06a, SignedHeaders=host;x-sdk-date, Signature=cb978df7c06ac242bab1d1b39d697ef7df4806664a6e09d5f5308a6b25043ea2

After obtaining the signed message headers, add them to the original HTTP request header with the Authorization and x-Authorization parameters. The request is sent to API Gateway for identity authentication. If the identity authentication is successful, the request is sent to the corresponding backend service for processing.

We use cookies to improve our site and your experience. By continuing to browse our site you accept our cookie policy. Find out more

Feedback

Feedback

Feedback

0/500

Selected Content

Submit selected content with the feedback