Design and Implementation of Secure RPC Interface Authentication and Anti‑Hijacking Mechanisms

Preface

Interface security is an eternal topic; APIs exposed to the front‑end require login, and third‑party APIs (referred to as "third‑party interfaces") also need authentication.

In the current environment, http restful (even non‑restful) is prevalent because it is simple and, performance‑wise, at least better than SOAP web services.

For third‑party interface authentication, many standard protocols exist, such as OAUTH2 , but the full OAUTH2 protocol imposes strict requirements on clients, and a trimmed‑down version often seems ineffective.

Beyond authentication, a major difficulty is anti‑hijacking ; if a request is hijacked, all subsequent requests, including authentication, become untrustworthy.

The only reliable measure against hijacking appears to be https , yet some sites still lack HTTPS, including systems that rarely get attacked but constantly receive vulnerability reports.

Nevertheless, adding layers of protection to raise attack cost is advisable, even if the system looks fine at first glance.

Overall Design

1.1 General Idea

The server maintains a client service list and only provides services to known clients.

The client holds two keys: a symmetric encryption key and an asymmetric public key; if both keys are leaked, call emergency services. Before sending a request, the client encrypts a small amount of information (e.g., client identifier) with the public key, encrypts the request body with the symmetric key, then salts the encrypted body (e.g., by combining the two keys) to generate a digest. The signature consists of the asymmetric‑encrypted string concatenated with the digest.

Upon receiving a request, the server looks up the client service list to obtain key information, compares the digest, decrypts the remaining part of the signature with its private key, and finally performs symmetric decryption.

1.2 Detailed Design

1.2.1 Service Attributes

Attribute Name

Chinese Explanation

Remarks

clientId

Service unique identifier

clientSecret

Symmetric key

privateKeyServer

Server private key

Held only by the server

publicKeyServer

Server public key

1.2.2 Client Processing Flow

Program participants:

Invoker: the caller, i.e., the program that references the library.

RpcEncrypt: the program entry point.

Signature: signature interface where client signing and server verification logic are implemented.

Digest: digest interface, default implementation is HMAC.

Asymmetric: asymmetric encryption interface, default implementation is RSA.

Symmetric: symmetric encryption interface, default implementation is AES.

Storage: storage interface, default implementation is in‑memory.

1.2.3 Server Processing Flow

1.2.4 Program Design

Code Implementation

GitHub: https://github.com/jiashuaizhang/rpc-encrypt

Gitee: https://gitee.com/cheapCabbage/rpc-encrypt

-- End --

If you have read this far, it means you like this public account's articles; please pin (star) the "Architect Guide" so you can receive pushes promptly.

In this public account "Architect Guide", reply with Architect to receive 2 TB of learning material!

Recommended Reading

Backend Architect Technical Guide (69 points)

How Should an Architect Design a Permission System?

How Can I Become an Architect?

Architect Builds an Order System from Scratch