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.

IT Architects Alliance
IT Architects Alliance
IT Architects Alliance
Secure RPC Encryption: Authentication, Anti‑Hijacking Design & Implementation

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-encrypt
Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Authenticationinformation securityAPI Securitycryptographyanti-hijackingRPC encryption
IT Architects Alliance
Written by

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.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.