HMAC vs digital signature: what each proves for webhooks

An HMAC and a digital signature both let a receiver check that a message wasn't changed and came from a key holder, but the keys differ. An HMAC uses one shared secret that both sides hold, so either side could have produced it. A digital signature is made with a private key only the signer holds and checked with a public key anyone can have. So an HMAC gives authenticity and integrity but not non-repudiation, and a digital signature gives all three.

The definitions are quoted from RFC 2104, RFC 4949, RFC 7518, RFC 7519 and NIST's glossary entries for message authentication code and digital signature. The Sume details come from its Run webhooks and Verifying webhooks docs. All were read on 2026-09-28.

What is an HMAC signature?

HMAC is a message authentication code (MAC) built from a cryptographic hash function and a secret key. RFC 2104, which defines it, describes MACs as integrity checks based on a secret key, typically used between two parties that share it. The sender computes the HMAC of the message with the key and sends it along; the receiver computes it again and compares. RFC 7518 notes that an HMAC can be used to demonstrate that whoever generated it was in possession of the key.

Because both sides hold the same key, either one could have made the tag. NIST's glossary sums up the result: MACs provide authenticity and integrity protection, but not non-repudiation protection.

How does HMAC differ from a digital signature?

In who holds which key. A plain hash is in the table for contrast:

What is the difference between HMAC and SHA-256?

SHA-256 is a hash function: it maps an input of any length to a fixed-length value, with no key, so anyone can compute the hash of any message. A hash sent next to a message catches accidental changes, but an attacker who changes the message can simply recompute it. HMAC-SHA256 is HMAC with SHA-256 as its hash function, so the result depends on the secret key as well as the message. RFC 7518 lists it as HS256, HMAC using SHA-256.

Why would a webhook use HMAC instead of a digital signature?

A webhook has one sender and one receiver, and only the receiver needs to check the signature. A shared secret fits that: the check needs only a hash function and the key, and non-repudiation adds little when no third party has to be convinced. The cost is that both sides hold the secret, so it must be guarded, and changed, on both.

Sume's webhooks work this way: each delivery carries an HMAC-SHA256 of <timestamp>.<raw_body>, hex-encoded as sume-v1=<hex_signature> in the x-sume-webhook-signature header, keyed with a secret derived for your workspace. Two features ease the shared-secret chores: a fingerprint header lets both sides confirm they hold the same secret without sending it, and after a rotation Sume signs with both the old and the new secret for 24 hours, so you can redeploy on your own schedule. Signed webhooks for Sume video runs covers the verifier.

Is a JWT signed with HMAC or a digital signature?

Either. RFC 7519 says a JWT's claims can be digitally signed or integrity protected with a MAC, and RFC 7518 lists both kinds of alg value. HS256 is HMAC using SHA-256 with a shared key. RS256 (RSASSA-PKCS1-v1_5 using SHA-256) and ES256 (ECDSA using P-256 and SHA-256) are digital signatures, made with a private key and validated with the matching public key. So HMAC vs JWT compares a signing method with a token format that can use it.

RFC 7518 also requires comparing an HMAC in constant time, to thwart timing attacks: the same rule a webhook verifier follows. Webhook security best practices lists the rest.