Designing Simple API Authentication for Internal Services

Scenario: Our B2B product includes a cloud‑operation platform that stores all project operation data. Although initially internal, other teams later needed to access the data, prompting a requirement for an interface authentication mechanism to identify calling services.

Solution explosion:

1. Private token in header or URL

约定client的token值为12345678，
那么请求的url地址为：
/remote/getApk?token=12345678

服务端接收到token后，进行匹配判断是否合法token，不合法就退出，合法就是后续操作。

This simple method lets the caller attach a static token, and the server validates it. However, the token can be intercepted, and relying solely on HTTPS may not be feasible for all internal services.

2. IP whitelist

The server checks the client’s IP address; if the token is hijacked, the request will be rejected because the IP does not match the whitelist. This requires no extra parameters and is easy to deploy, but can be bypassed with IP spoofing or proxying.

3. Salted token with signature (sign) and timestamp

Prerequisites:

IP whitelist

Generate a token (salt) for the caller

这里约定就不是token了，使用一个双方约定的密码盐值salt=123456

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

The sign is calculated by sorting request parameters by key, concatenating their values with the salt, and applying an MD5 (or other hash) function. The server reproduces the same calculation to verify the request.

To prevent replay attacks, a timestamp is added to the URL:

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

The timestamp makes the signature valid only for a short window (e.g., one minute). The server can reject requests with expired timestamps, and a bucket‑based cache can store used signatures to prevent duplicates.

Time synchronization issues can be mitigated by using a shared time server or having the client periodically sync with the server.

Summary: For internal service‑to‑service calls, a lightweight authentication scheme based on IP whitelist, static or salted tokens, and time‑bound signatures can be sufficient, avoiding the complexity of JWT or OAuth2 while still providing reasonable security.