Design and Implementation of Secure RPC Encryption for Backend Services

Preface

Interface security is an evergreen topic; APIs exposed to the front‑end must require login, and third‑party APIs also need authentication.

In the current environment, http restful (even non‑RESTful) is prevalent because it is simple and generally performs better than SOAP.

Standard protocols for third‑party authentication include OAUTH2, but the full OAUTH2 spec is often too demanding for clients, and trimmed‑down versions may be of limited use.

Beyond authentication, preventing request hijacking is critical—once hijacked, all requests become untrustworthy.

The only reliable anti‑hijacking measure is https, though some legacy systems still operate without it.

Even without perfect solutions, adding layers of protection raises the attack cost and makes the system appear safe at a glance.

Overall Design

1.1 General Idea

The server maintains a whitelist of client services and only serves known clients.

Each client holds two keys: a symmetric encryption key and an asymmetric public key. Before sending a request, the client encrypts a small identifier with the public key, encrypts the request body with the symmetric key, and then salts the encrypted body (e.g., by combining both keys) to generate a digest. The signature consists of the asymmetrically encrypted string concatenated with the digest.

Upon receiving a request, the server looks up the client’s credentials, verifies the digest, decrypts the signature with its private key, and finally decrypts the request body symmetrically.

1.2 Detailed Design

1.2.1 Service Attributes

Attribute Name

Chinese Description

Notes

clientId

Service unique identifier

clientSecret

Symmetric key

privateKeyServer

Server private key

Only held 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 service.

RpcEncrypt: the entry point of the program.

Signature: implements client‑side signing and server‑side verification.

Digest: default implementation is HMAC.

Asymmetric: default implementation is RSA.

Symmetric: default implementation is AES.

Storage: default implementation is in‑memory storage.

1.2.3 Server Processing Flow

The server validates the client’s signature, checks the digest, decrypts with its private key, and finally decrypts the request body symmetrically.

1.2.4 Program Design

All components are modular and can be swapped as needed.

Code Implementation

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

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

For further discussion, readers are encouraged to join the “Top Architect” community, scan the QR codes provided, or reply with keywords to receive additional resources.