How a Key Gateway Secures Third‑Party API Calls and Prevents Key Leaks

Background

As internet applications increasingly rely on multiple third‑party services (e.g., Alipay, WeChat Pay, map APIs), developers must integrate various OpenAPI interfaces, each with its own signing and encryption rules. Keys are often hard‑coded or stored in configuration files, leading to significant security gaps.

Problem Identification

Code risk: In early development stages, keys are managed by business developers and may be committed to source repositories, making them visible to anyone with code‑read access.

Personnel risk: Even with a centralized KMS, developers can retrieve keys at runtime, log them, or misuse them, and such actions are hard to detect.

Traditional Solution

Directly embed keys in code or configuration, requiring developers to handle signing and encryption for each third‑party service. This approach leads to duplicated effort, long development cycles, and high leakage risk.

Ideal Solution

Introduce a dedicated key‑management system (KMS) that stores keys securely and provides APIs for retrieval, reducing direct exposure. However, developers can still access keys via debugging or custom scripts.

Key Gateway Architecture

The proposed Key Gateway acts as an intermediate layer that isolates business services from raw keys. It combines three roles:

Key storage side: Holds keys and never knows business logic.

Service caller side: Knows business logic but cannot obtain raw keys.

Service provider side: Third‑party services remain unaware of the gateway.

The gateway performs request signing, encryption, token acquisition, and response decryption before forwarding calls to third‑party APIs.

Core Modules

Signature module: Generates simple signatures (AppKey + AppSecure) or two‑step verification (token acquisition + signing).

Token management: Retrieves, caches, and refreshes access tokens as needed.

Key management: Stores keys in KMS with version control.

Outbound gateway: Forwards signed requests and handles timeout, rate‑limit, and error handling.

Custom Mode

To avoid repetitive development‑test‑deploy cycles, a JavaScript interpreter is embedded, allowing developers to write signing logic directly in the backend UI. The interpreter includes common sorting and cryptographic functions, enabling real‑time updates without code redeployment.

function (reqHeaders, reqParams, reqBody, AppKey, AesKey, AesIV, PrefixUrl, TokenUrl) {
    var ts = reqBody.get('timestamp');
    var token = token_load();
    if (!token) {
        var reqData = {
            "appKey": AppKey,
            "data": base64_encode(aes_cbc_pkcs5_encrypt(AesKey, '{"appKey": "' + AppKey + '"}', AesIV)),
            "timestamp": ts
        };
        reqData["sign"] = sha256("appKey=" + AppKey + "&data=" + reqData["data"] + "×tamp=" + ts).toUpperCase();
        var respObj = JSON.parse(http_post_json(TokenUrl, reqData, {}));
        if (respObj["data"]["accessToken"]) {
            token = "Bearer " + respObj["data"]["accessToken"];
            token_save(token, respObj["data"]["expireTime"]);
        }
    }
    reqHeaders.set("Authorization", token);
    reqHeaders.setURI(PrefixUrl + reqHeaders.getURI());
    var originData = reqBody.get('data');
    var enData = base64_encode(aes_cbc_pkcs5_encrypt(AesKey, originData, AesIV));
    reqBody.set("appKey", AppKey);
    reqBody.set('data', enData);
    var sign = sha256(reqBody.buildSignStr()).toUpperCase();
    reqBody.set('sign', sign);
}

Signature Workflow

Obtain token (if required).

Fill or modify request parameters.

Sort parameters.

Generate the string to be signed.

Compute the signature.

Insert the signature into the request.

Process the response (decrypt, reformat, clear token cache).

Simple signatures usually need steps 2‑6, while two‑step verification adds step 1.

Multi‑Tenant, Multi‑Version, Multi‑Role Design

Each business unit is treated as a tenant with its own AppKey. Tenants can configure timeouts, bind keys, edit signing rules, and manage service lifecycle independently. Versions allow safe roll‑backs of configuration changes. Roles (gateway admin, tenant admin, tenant developer) enforce granular permissions and audit trails.

Exception Handling

The gateway anticipates failures such as third‑party timeouts, configuration or key retrieval failures, and deployment issues. Default TCP and HTTP timeout values are set per service and can be adjusted in real time. Deployment failures trigger node removal, while restart logic falls back to cached configurations to maintain availability.

Conclusion

The Key Gateway provides a unified, secure middle layer for third‑party API integration, reducing key exposure, simplifying signing logic, supporting multi‑tenant management, and ensuring high availability through robust error handling. Ongoing optimization will focus on further reducing integration effort while preserving stability.