Secure RPC Encryption: Authentication, Anti‑Hijacking Design & Implementation
This article examines the challenges of securing API interfaces—including authentication for third‑party services and protection against request hijacking—and proposes a comprehensive RPC encryption framework that uses asymmetric and symmetric keys, signed payloads, and HTTPS fallback, detailing both client‑side and server‑side workflows, data structures, and providing links to the full source code.
Introduction
The article discusses the enduring problem of interface security, emphasizing the need for authentication on both front‑end APIs and third‑party service APIs, as well as the difficulty of preventing request hijacking.
Challenges
Modern systems favor http restful APIs for simplicity and performance, but they lack built‑in security.
Standard protocols like OAUTH2 are often too heavyweight for many clients.
Even with authentication, hijacked requests become untrustworthy.
Using https is the most reliable mitigation, yet many legacy systems still operate without it.
Overall Design
The proposed solution maintains a server‑side list of authorized clients and requires each client to hold two keys: a symmetric key ( clientSecret) and an asymmetric public key. The client encrypts a small identifier with the public key, encrypts the request body with the symmetric key, then combines the encrypted payload with a salted hash to form a signature. The server validates the signature, decrypts the payload, and processes the request.
Detailed Design
Key attributes for each client record:
clientId : unique identifier of the service.
clientSecret : symmetric key.
privateKeyServer : server’s private key (kept only on the server).
publicKeyServer : server’s public key.
Client Processing Flow
Components involved on the client side:
Invoker: the caller of the RPC.
RpcEncrypt: entry point for encryption.
Signature: creates the signature using the asymmetric key and hash.
Digest: default implementation uses HMAC.
Asymmetric: RSA‑based encryption.
Symmetric: AES‑based encryption.
Storage: in‑memory storage for keys.
Server Processing Flow
When the server receives a request, it looks up the client’s record, verifies the hash, decrypts the signature with its private key, and finally decrypts the payload with the symmetric key.
Implementation
The full source code, including client and server modules, is available on GitHub and Gitee:
GitHub: https://github.com/jiashuaizhang/rpc-encrypt Gitee:
https://gitee.com/cheapCabbage/rpc-encryptSigned-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
IT Architects Alliance
Discussion and exchange on system, internet, large‑scale distributed, high‑availability, and high‑performance architectures, as well as big data, machine learning, AI, and architecture adjustments with internet technologies. Includes real‑world large‑scale architecture case studies. Open to architects who have ideas and enjoy sharing.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
