Secure One‑Time Token Design for Long‑Connection Services

The article explains the challenges of protecting long‑connection services from abuse and presents a one‑time secure token architecture—including gateway SDK, token generation, Redis caching, and verification modules—to ensure authentication, prevent replay attacks, and improve service robustness.

JD Retail Technology
JD Retail Technology
JD Retail Technology
Secure One‑Time Token Design for Long‑Connection Services

With the rapid shift of services to online platforms, traditional short‑connection request models struggle to meet the demands of high‑volume, long‑connection scenarios, making careful strategy design essential to protect backend resources from malicious attacks that can degrade availability and stability.

Common long‑connection attack patterns include interface flooding and identity spoofing; flooding can exhaust connection limits, while spoofed identities enable unauthorized requests, both threatening service reliability.

Existing cookie‑based authentication methods suffer from three major drawbacks: inability to verify the requester’s identity, reuse of credentials allowing repeated attacks, and susceptibility to tampering because the data resides on the client side.

The proposed solution introduces a secure token workflow tailored for long‑connection use cases. Before establishing a connection, the client obtains a one‑time token from a third‑party service; the token is never stored on the client and is regenerated for each connection attempt.

The architecture consists of six modules: Gateway SDK (generates request signatures), Gateway (validates signatures), Token Generation (creates unique tokens using device UUID and timestamp, records them in a Redis cache), Redis Cache Cluster (stores token‑UUID mappings), Verification Module (checks token existence and consumes it), and Long‑Connection Service (handles business logic after successful verification).

Operational steps include: the client generates a signature via the SDK; the gateway validates the signature; the token module checks request freshness, records UUID‑timestamp, generates and stores a token; the verification module validates the token against the cache and consumes it; finally, the long‑connection service processes the request.

This design ensures token uniqueness, strong identity verification, and resistance to tampering, thereby enhancing anti‑flood capabilities, authentication integrity, and data consistency for long‑connection services.

Overall, the adaptive invalid‑request filtering scheme offers benefits such as one‑time token usage, device‑bound authentication, immutability of tokens, and improved backend service robustness against malicious traffic.

backendRedisAuthenticationlong connectionanti-floodSecurity Token
JD Retail Technology
Written by

JD Retail Technology

Official platform of JD Retail Technology, delivering insightful R&D news and a deep look into the lives and work of technologists.

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.