3 ms·

If only there was a single standard for webhook subscription verification. Cloud services invent their own authentication protocols. Webhook verification in Dro

If only there was a single standard for webhook subscription verification. Cloud services invent their own authentication protocols. Webhook verification in Dropbox is different from that in Trello. The lack of a single standard makes it hard to design a universal incoming webhook service (we faced this problem).

tasn 4y ago
Amen. FWIW, we are open source, and we publish libraries that let anyone sign and verify webhooks, hoping to save people the work and have a unified standard. Libs: https://github.com/svix/svix-webhooks https://github.com/svix/svix-webhooks Docs: https://docs.svix.com/receiving/verifying-payloads/how-manual https://docs.svix.com/receiving/verifying-payloads/how-manua... The docs mention `Svix-Signature`, but we (and the libs) also support `Webhooks-Signature` which are useful for the generic standard. The fact that we don't have REST for webhooks is both silly and annoying. Especially since (as you can see on the list in the original post) many companies who implement webhooks end up doing it poorly.
caseysoftware 4y ago
I love the idea of a standard but it gets colorful as you start digging in what the individual leaders are doing. On the signature front, there's this but it's not enough: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures-11 https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-mes...
leetrout 4y ago
One option is to use a platform like we created at https://hookdeck.com/ https://hookdeck.com/ where we handle verification with multiple providers and then offer downstream destinations a verifiable request (the Hookdeck signature is a SHA-256 based HMAC digest). Drop Hookdeck in as a proxy between the origin service and your destination and you get seamless integrations that help with reliability, observability, and recovery (request replays).

tasn 4y ago

Amen. FWIW, we are open source, and we publish libraries that let anyone sign and verify webhooks, hoping to save people the work and have a unified standard. Libs: https://github.com/svix/svix-webhooks https://github.com/svix/svix-webhooks Docs: https://docs.svix.com/receiving/verifying-payloads/how-manual https://docs.svix.com/receiving/verifying-payloads/how-manua... The docs mention `Svix-Signature`, but we (and the libs) also support `Webhooks-Signature` which are useful for the generic standard. The fact that we don't have REST for webhooks is both silly and annoying. Especially since (as you can see on the list in the original post) many companies who implement webhooks end up doing it poorly.

caseysoftware 4y ago

I love the idea of a standard but it gets colorful as you start digging in what the individual leaders are doing. On the signature front, there's this but it's not enough: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures-11 https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-mes...

leetrout 4y ago

One option is to use a platform like we created at https://hookdeck.com/ https://hookdeck.com/ where we handle verification with multiple providers and then offer downstream destinations a verifiable request (the Hookdeck signature is a SHA-256 based HMAC digest). Drop Hookdeck in as a proxy between the origin service and your destination and you get seamless integrations that help with reliability, observability, and recovery (request replays).