I want to sign webhooks so that client services can verify that a request came from my service.

Looking around, it seems that most SaaS use symmetric keys shared by the client and the SaaS. Obviously, there's an overhead of generating and storing a unique secret for each client here.

It seems to me like asymmetric crypto is an easier solution here: sign the payload with a private key, publish the public key on your website, and you avoid the overhead of maintaining shared secrets for each client.

Given the above, is there a good reason many reputable SaaS (GitHub, Stripe, Slack etc.) opt for using shared secrets for signing webhooks? What are the tradeoffs of the approaches?


Asymmetric encryption is more useful when communication is with untrusted parties since you can keep the private key safe while sharing the public key more loosely.

Symmetric is more useful between trusted parties as the key is needs to be more secure.

So if the purpose of the webhook is to integrate a trusted application to post messages to your Slack channel, symmetric encryption is fine.

  • "the key ... needs to be more secure" -- not quite. The key needs to be communicated securely and stored and managed securely on both ends. Asymmetric keys only need to be secured on the private end and the public key does not need to be communicated or secured at all. The key itself does not need to be more secure than the other. – schroeder Dec 5 '19 at 9:58
  • "a trusted application" -- again, not quite. Given the above correction, it's not about trust it's about control. If you control and can protect both ends, using a symmetric key is fine. – schroeder Dec 5 '19 at 10:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.