Designing Simple Yet Secure API Authentication for Internal Services

Scenario

Our product is a B2B cloud operation platform that stores operational data for all projects. Initially we did not need to expose services externally, but a request arose when another team needed our data.

Requirement

We need an interface authentication mechanism to identify the calling service.

Solution Explosion

1. Private token in header or URL

client token = 12345678
GET /remote/getApk?token=12345678
// Server validates token and proceeds if valid

This is simple, but vulnerable if the token is intercepted.

Using HTTPS adds encryption, but full HTTPS may be impractical for small internal services.

2. IP whitelist

The server can obtain the client’s IP address and allow only whitelisted IPs, making a stolen token useless.

However, IP spoofing or proxying could still bypass this.

3. Token as salt and mutual signature

Prerequisites:

IP whitelist

Generate a token (salt) for the caller

salt = 123456
GET /remote/getApk?md5=043c00e6c7ff021e8cc4d394d3264cb5&sign=md5(043c00e6c7ff021e8cc4d394d3264cb5+123456)

The server recomputes the signature and verifies it. This still does not prevent interception.

Adding a timestamp

GET /remote/getApk?t=1561969549&md5=043c00e6c7ff021e8cc4d394d3264cb5&sign=md5(043c00e6c7ff021e8cc4d394d3264cb5+1561969549+123456)

The timestamp makes the signature valid only for a short period (e.g., one minute). The server checks the time drift and rejects expired requests.

To avoid mismatched clocks, either synchronize both sides with a common time server or let the client periodically sync with the server’s time.

Conclusion

The described scheme is suitable for internal service‑to‑service calls where heavyweight solutions like JWT or OAuth2.0 are unnecessary. If needed, those standards can be adopted, turning the call flow into login, validation, and authorization steps.