API Interface Security: AccessKey/SecretKey, Token/AppKey, Signature Generation and Replay‑Attack Prevention

Interface Security Issues

Is the request identity legitimate?

Has the request parameters been tampered with?

Is the request unique?

AccessKey & SecretKey (Open Platform)

Identity Verification

Each developer receives a unique AccessKey (identifier) and a SecretKey (used for request encryption, hard to guess or brute‑force).

Preventing Tampering – Parameter Signature

Signature algorithm:

Sort all non‑empty request parameters (including AccessKey) alphabetically, concatenate them as a URL‑encoded string stringA (e.g., key1=value1&key2=value2… ).

Append the SecretKey to stringA to obtain stringSignTemp .

Compute the MD5 hash of stringSignTemp , convert the result to uppercase, yielding the sign value.

The request must carry both AccessKey and sign ; only requests with a valid identity and correct signature are accepted.

Replay Attack Mitigation

Even with signature verification, an attacker could reuse a signed request. The timestamp+nonce scheme solves this:

nonce is a unique random string identifying each signed request.

The server stores used nonces (e.g., in Redis) and rejects any request with a previously seen nonce.

To limit storage, a timestamp is added; only nonces within a configurable time window (e.g., 15 minutes) are kept.

When a new request arrives, the server checks that the timestamp is within the allowed window and that the nonce has not been used; if both checks pass, the nonce is recorded and old entries are expired.

Implementation Example (Client)

http://api.test.com/test?name=hello&home=world&work=java

Generate current timestamp and a random nonce .

Build stringA by sorting parameters (including AccessKey, timestamp, nonce): AccessKey=access&home=world&name=hello&work=java&timestamp=now&nonce=random

Append SecretKey to obtain stringSignTemp : AccessKey=access&home=world&name=hello&work=java&timestamp=now&nonce=random&SecretKey=secret

Compute sign = MD5(stringSignTemp).toUpperCase() .

Send the final request: http://api.test.com/test?name=hello&home=world&work=java&timestamp=now&nonce=nonce&sign=sign

Token & AppKey (APP)

For mobile/app APIs that handle personal or sensitive data, token‑based authentication is used. After a successful login, the server returns a Token which the client stores and includes in every subsequent request.

Token Validation

User logs in with credentials; server returns a token.

Client stores the token locally.

Each request carries the token; the server verifies its validity and expiration.

If the token is compromised, an attacker could forge requests, but the token alone does not expose the secret key.

Token + AppKey Signature Verification

Similar to the open‑platform method, the client receives an AppKey (a secret used only for signing). The client combines the token, AppKey, and all request parameters, generates a signature, and sends both the token and signature. Even if the token is stolen, without the AppKey and signing algorithm the request cannot be forged.

Implementation Example (App)

Login/Logout flow is illustrated with diagrams (omitted). Subsequent requests follow the same steps as the open‑platform client, replacing AccessKey with the Token while keeping the signature process identical.

By combining token/AppKey signing with the timestamp‑nonce replay‑prevention strategy, API calls are protected against identity theft, parameter tampering, and replay attacks.