HMAC

The construction hashes the message twice with the key mixed in through two different padding constants, which is what makes it resistant to the extension attacks that a naive key and message concatenation allows. That construction also means its security does not collapse the moment collisions are found in the underlying hash, which is why HMAC built on older hash functions remained sound for authentication after those hashes were retired for signatures.

The distinction from a digital signature is the one that matters commercially. With a shared key, either party could have produced the value, so it cannot be used to prove to a third party who sent something. Where a dispute has to be settled, the requirement is a signature with a private key, not this.

Three findings recur in API work. Verification performed with an ordinary string comparison, which returns early on the first differing byte and leaks the correct value through timing. Signatures computed over part of a request only, so an attacker can alter an unsigned header, the method or a query parameter and keep the value valid. And a symmetric JWT signed with a short shared secret that is a password rather than a random key, which is cracked offline once a single token is captured. All three are standard checks in the API testing where request signing and token verification are examined.