How HMAC authentication works for web api

just was reading a article on web API with HMAC authentication from this url http://www.piotrwalat.net/hmac-authentication-in-asp-net-web-api/

if possible some one briefly discuss what is HMAC authentication and How this type of authentication works for web api ?

what i understood from their article that client will have a secret key and when client will request web api service then they will send hash of secret key along with request and web service will compare the hash and if match then it allow to call action ?

if i understood correctly then i have some question. suppose if am sending hash of a secret key to web api then how web api know what key client have ? because if web api has to generate hash of secret key what client used for comparing at service end then web api has to know which client is sending data.

there is change of Replay attack for HMAC authentication for web api

the article raise some points which is not clear to me to prevent the chance of Replay attack for HMAC authentication for web api.

the points are

Imagine a malicious third party intercepts a valid (properly authenticated) HTTP request coming from a legitimate client 
(eg. using a sniffer). Such a message can be stored and resent to our server at any time enabling attacker to repeat operations 
performed previously by authenticated users. Please note that new messages still cannot be created as the attacker does not 
know the secret nor has a way of retrieving it from intercepted data.

1) requests with different Date header values will have different signatures, thus attacker will not be able to modify the timestamp

we will generate hash based on secret key then how date comes to scene ? this points is not clear to me.

2) we introduce a requirement that no http request can be older than X (eg. 5) minutes - if for any reason the message is

delayed for more than that it will have to be resent with a refreshed timestamp.

point two is not clear. what this area try to mean delayed for more than that it will have to be resent with a refreshed timestamp.