Preventing resubmission and replay attack using client nonce in REST API

Question

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?

Answer 1

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.

Answer 2

(All REST call are though HTTPS)

Then you're already protected against replay attacks.