Incoming webhooks signing secret approach to HMAC validation

I had an email conversation a while back with Ross Grambo about the current state of the HMAC validation system used by Asana. Currently, incoming webhooks contain an SHA256 HMAC signature computed on the request body using the shared secret transmitted during the handshake. I expressed that seemed like an unnecessary amount of overhead just to validate an incoming webhook. Specifically because it requires a round trip to the database just to find that shared secret for the specific asana user whom we have a webhook subscription on their behalf. This also means I have to add an index to my database just to validate incoming webhooks from Asana.

We discussed the option of using a shared signing secret - which is the approach many other SaaS API’s use (Slack, Stripe, etc.). Just wondering if you guys are having a conversation about this internally still, or whether I should jump through the hoops to get your current HMAC validation approach implemented into our system.

Eric Froese


Hello again @Eric_Froese,

We talked about it and it may be something we move to in the future, but for now it’s not on our roadmap. You’re best off implementing our current validation approach.