API Authentication and Request Signing with AccessKey/SecretKey, Token, and AppKey

Interface Security Issues

Key questions include whether the request identity is legitimate, whether request parameters have been tampered with, and whether each request is unique.

AccessKey & SecretKey (Open Platform)

Identity Verification

Developers are assigned a unique AccessKey (identifier) and a SecretKey (used for request encryption, hard to guess).

Preventing Tampering – Parameter Signature

Sort non‑empty request parameters (including AccessKey) alphabetically and concatenate them as a URL‑encoded string stringA (e.g., AccessKey=access&home=world&name=hello&work=java ).

Append the SecretKey to stringA to obtain stringSignTemp .

Compute the MD5 hash of stringSignTemp , convert the result to uppercase, and use it as the sign value.

The request must carry both AccessKey and Sign; only requests with a valid AccessKey and correct Sign are allowed.

Replay Attack Mitigation – timestamp+nonce

A nonce is a unique random string that identifies each signed request. The server records used nonces to prevent reuse. To avoid storing all nonces indefinitely, a timestamp is added; only nonces within a 15‑minute window are accepted.

When a new request arrives, the server checks that the timestamp is within the allowed range and that the nonce has not been seen before; otherwise the request is rejected. Accepted nonces are stored (e.g., in Redis with a 15‑minute expiry).

Implementation Example

Client side

Generate current timestamp=now and a random nonce=random .

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

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

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

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

Server side – verify the signature, timestamp, and nonce (often using Redis for nonce expiry).

Token & AppKey (APP)

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

Token Authentication Flow

User logs in with credentials; server returns a Token.

Client stores the Token locally and attaches it to each request.

Server validates the Token; if valid, the request proceeds, otherwise it is rejected.

Security risk: a stolen Token can be used to forge requests and tamper with parameters.

Token + AppKey Signature Verification

Similar to the Open Platform method, the client receives an AppKey (a secret not transmitted over the network). The client combines the AppKey with all request parameters to form a source string, generates a signature, and sends both the Token and signature with the request. Even if the Token is compromised, without the AppKey and signing algorithm the attacker cannot forge or replay requests.

Implementation Notes

Login/Logout requests follow the same pattern as the Open Platform, with the AccessKey replaced by the Token.

Subsequent requests – client includes Token (instead of AccessKey) and signs the request with AppKey; server verifies the signature and applies the same timestamp‑nonce replay protection.

— END —