[tagx]

"being able to encrypt a message is proof that they are who they say they are"

This is not exactly right. Encryption ensures people cannot eavesdrop on a message but it does not ensure you can verify the sender. You need authentication instead, which is what HMAC does in this case.

[brettcvz]

In general that's true, but specifically referring to public-key encryption only the holder of the private key will be able to create an encrypted message, so it serves as authentication

[wglb]

But what if an attacker intercepts this encrypted message and replays it?

[rkalla]

You can either use a timestamp (that is included in the HMAC calculation to ensure it isn't changed) to allow a replay-window (this is what AWS does) or you can utilize a NONCE value retrieved from the server before hand and recorded as "played" once it is used so no other requests can ever be sent using that nonce.

[Xylakant]

Using a NONCE has some advantages and some disadvantages. There's no need to retrieve the nonce from the server, the client can generate any random value and include it in the signature. However, one of the beautiful properties of HMACs is that the server you're talking to does not need any stored information other than the shared secret to authenticate the request. That makes HMAC-Authentication feasible over a cluster of servers that share no storage if the secret is fixed. Using a NONCE requires that the servers share a storage that updates pretty much immediately, so they all need access to the same datastore that must have practically no replication delay. Otherwise an attacker could still replay the request, just against a different server.

[rkalla]

Excellent callouts about the NONCE, thanks for adding them! (great points about how this impacts your backend)