Incoming webhooks signing secret approach to HMAC validation

English Forum Developers & API
1

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.

Sincerely,
Eric Froese

2

@Ross_Grambo

3

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.

Best,
Ross

4

Hello @Ross_Grambo - can I second this request please, for allowing the caller to provide a secret. It would be totally cool if you have requirements on that secret format (such as being 32char hex encoded for example, or whatever). One of our issues is that we’d like to point webhooks for all projects for the same user to the same webhook endpoint. But then the webhook may have many different secrets and we have to check them all.

So right now having to go though the extra overhead of refactoring our system to support the current idiosyncratic way of having a secret per webhook really incentivizes us to put off that work, and not validate for a while.

1 Like