Webhook Authentication
Webhook authentication is the process of verifying the identity and legitimacy of webhook requests coming from the webhook service to the webhook receiver. It is a critical security measure: a webhook endpoint is a publicly reachable URL that accepts POST requests, so without authentication, anyone who discovers the URL can send fake events and have them processed as real ones.
That failure mode is worse than it sounds. A forged "payment succeeded" event can trigger order fulfillment; a forged "user verified" event can grant access. By implementing webhook authentication, applications ensure that only genuine webhook requests are processed, protecting the integrity of every workflow that webhooks trigger.
Authentication methods that don't fit webhooks
Several familiar authentication methods are poor fits for webhooks, and it's worth understanding why.
Basic Authentication sends static credentials with every request, so a single leaked delivery log exposes them, and it says nothing about whether the request body was modified in transit. An API key in the URL is worse: URLs are recorded in server logs, proxy logs, and analytics tools, so the key leaks constantly by design. Cookie-based authentication assumes a browser session and doesn't fit server-to-server calls at all. And mTLS, while cryptographically sound, imposes certificate management on every receiver, which is unrealistic when your receivers are thousands of customers with varied infrastructure.
What to use instead
The recommended best practice for webhook authentication is signing. The sender computes an HMAC signature over each payload using a per-endpoint secret, and the receiver verifies the webhook signature before trusting the request. This proves both origin and integrity in a single check, and including a signed timestamp defeats replay attacks, where a captured legitimate request is re-sent later.
Signatures should be layered with transport and operational controls: deliver exclusively over HTTPS so payloads and headers can't be read in transit, optionally validate the sender's published IP addresses as a defense-in-depth measure, and rate limit and monitor your endpoint so abuse is visible. None of these substitutes for signature verification, but together they close off the remaining angles.
Authentication on both sides
Webhook authentication usually refers to receivers verifying senders, but the reverse direction matters too. Senders should protect themselves from malicious endpoint registrations, which is the domain of SSRF prevention, and receivers that expose webhook URLs should keep them unguessable so authentication is the second line of defense rather than the only one.
For more on webhook authentication, check out our documentation on additional webhook authentication methods.