HMAC
A keyed hash. Proves a message came from someone who holds the key.
What it does
A plain hash tells you whether data has changed. It cannot tell you who produced it, because anyone can compute a hash of anything.
HMAC mixes a secret key into the hashing process. The result can only be produced, and only be checked, by someone holding that key. That turns “this data is intact” into “this data came from someone I share a secret with”, which is a far more useful statement.
What it is for
Signing API requests, validating webhook payloads, session cookies and tokens, and any case where a receiver needs to reject anything that did not come from the expected sender.
If you have ever verified a webhook from a payment provider, you have compared an HMAC.
Two things people get wrong
Do not build your own by concatenating a key and a message and hashing it. That naive construction is vulnerable to length-extension attacks against the SHA-2 family, where an attacker who never learns the key can still append data and produce a valid-looking digest. HMAC’s nested construction exists specifically to prevent that.
Compare digests in constant time. A normal string comparison returns as soon as it finds a difference, and the timing of that return leaks how much of the digest was correct, one byte at a time.
Verification
Checked against the RFC 2202 vectors for SHA-1 and the RFC 4231 cases for the SHA-2 family, which cover short keys, keys longer than the hash block size, and keys requiring padding.
Related
Hash is the same set of algorithms without a key.