Preventing resubmission and replay attack using client nonce in REST API

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.