I have a REST API backend which has HTTPS (and blocked HTTP) and use JWT as the authentication mechanism. The client side is iOS/Android app. I want to add a layer of safeguard on critical API by using client nonce to prevent (mostly) resubmission (unintentionally calling the same API twice due to bad network/UI) and (maybe) replay attack. The current details are as follows.

(All REST calls are through HTTPS)

  1. The client makes an API call using username and password to exchange for a JWT from server side.
  2. The client uses the JWT obtained (HTTP header) and makes subsequent API call to the server.
  3. The backend server checks the JWT and executes the request.

The current issue is, anyone who can intercept the HTTP package can replay the API call. Moreover, in the situation with a bad network, the client may press the submit/confirm button twice and resubmit the request.

What I propose is the following:

  1. The client makes an API call using username and password to exchange for a JWT from server side.
  2. The client uses the JWT obtained + a client-generated nonce and makes subsequent API call to the backend server.
  3. The backend server checks the JWT first and then the nonce. Let's assume we have a k-v store with TTL like Redis.
  4. If the nonce exists in Redis, we reject the request. If not, we accept the request and set the nonce in Redis with some predefined TTL (say 1hr?) so that a replay will be rejected.

I have to admit I have very little knowledge on security. I want to know if this proposal is legit? Or I miss something important? If my idea is ok, what is the best algorithm to generate the nonce? Does the server side need to somehow "decode" the nonce to see if it fits the protocol before comparing it against Redis?

  • 2
    Since you're using https why are you worrying about someone to "intercept the http package"? https as such is already replay safe.
    – kaidentity
    Commented Aug 5, 2016 at 15:02
  • ok, so my remaining concern remain is client side resubmission
    – mingchuno
    Commented Aug 5, 2016 at 15:19

2 Answers 2


A client-side nonce presents three difficulties:

  • how does the client know when to generate a new nonce? (What actions constitute a new request such that a new nonce should be generated for it?)

  • how does the server know what's a valid nonce? Can a hypothetical attacker-supplied 4gb blob be a nonce?

  • how does the server know how many nonces to keep and for how long?

A server-provided nonce provides two benefits:

  • less for the client to do
  • the server knows what to expect next

The server doesn't have to keep a record of all nonces, just the current one, and it can be deleted when the first valid request with it arrives. A new nonce can be sent with the response.

This model enforces a one-request-in-flight interaction model. Should there be a desire for multiple concurrent requests, the server can produce a block of nonces, but the challenge again is that client needs a model for differentiating between unique requests, ensuring that each user action doesn't result in pulling a new nonce from the local pool. This difficulty should suggest structuring the app in a way such that only one nonce-required request be in flight at a time.


(All REST call are though HTTPS)

Then you're already protected against replay attacks.

  • 1
    https prevents replay attacks only at the network level, i.e. a man-in-the-middle can't replay an intercepted https request, thanks to the protocol. But the client (hacked, network problems, etc) can resend the same original request, seen as different requests from a http point of view. Commented Jan 20, 2019 at 1:27
  • @curiousBoy Please explain
    – Iter Ator
    Commented Jan 31, 2021 at 16:48
  • this is untrue. any client that has its comms mitm'ed with correct certificates, or lack of certificate checking/validation, can be subjected to replay attacks. with the exceptions of banks and high value targets, no one bothers implementing relay attack protection, but they should as it opens up a huge attack vector. Commented Dec 11, 2023 at 10:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .