11–20 of 33 posts
Why do so many webhooks use HMAC signatures for authorization?
For everything else in APIs, people are perfectly happy to use API tokens/secrets directly in headers.
Why don't webhooks directly share secrets, instead of HMAC signatures?
Like, I understand the advantages of HMAC, but for some reason it seems to be that webhooks are unique in their usage of it.
I wondered, "whose standard?", and was pleasantly surprised to find a list of real names [1] on the website. Nonetheless, I do bristle at the semantic weight of the name despite the fact it's not attached to a relevant existing institution. [1]: https://www.standardwebhooks.com/#committee
webhooks were a phase we should have passed by now, not try to entrench with some standard. it’s a broken/obscure implementation of full duplex communications between two systems but thought up as if it were a luxury, auxiliary system whose downtime we should be able to tolerate. if we’re required to survive downtime of a webhook system, i think we’re right to ask: why are they there in the first place?
Good sign to me is one of the steering members is Tom Hacohen founder of Svix (webhooks-as-a-service). We're adopting them where I work and everything from them has been solid. I know he's seen a lot of different use cases and will have good consideration for the schema they define in their spec file.
Question: Why do so many webhooks use HMAC signatures for authorization? For everything else in APIs, people are perfectly happy to use API tokens/secrets directly in headers. Why don't webhooks directly share secrets, instead of HMAC signatures? Like, I understand the advantages of HMAC, but for some reason it seems to be that webhooks are unique in their usage of it.
A shared secret alone, or an HMAC based on a shared secret, just means any party with the secret -- which could include anyone who would need to verify it -- composed the message.
I generally don't do what's advocated for in the article because it doesn't make a lot of sense, I do either:
- A shared secret
- A signed and HMACed payload with asymmetric key
Question: Why do so many webhooks use HMAC signatures for authorization? For everything else in APIs, people are perfectly happy to use API tokens/secrets directly in headers. Why don't webhooks directly share secrets, instead of HMAC signatures? Like, I understand the advantages of HMAC, but for some reason it seems to be that webhooks are unique in their usage of it.
The only advantage is that it validates that the send composed the message in the case without a shared secret (which is not what the article appears to advocate for). A shared secret alone, or an HMAC based on a shared secret, just means any party with the secret -- which could include anyone who would need to verify it -- composed the message. I generally don't do what's advocated for in the article because it does…
webhooks were a phase we should have passed by now, not try to entrench with some standard. it’s a broken/obscure implementation of full duplex communications between two systems but thought up as if it were a luxury, auxiliary system whose downtime we should be able to tolerate. if we’re required to survive downtime of a webhook system, i think we’re right to ask: why are they there in the first place?
what is your suggestion for duplex communication?
Earlier quoted context omitted.
what is your suggestion for duplex communication?
I'm not totally anti-webhook or the person you replied to, but I'd prefer at-most-once delivery via something that establishes a reusable connection (grpc or even websockets?) and backed by an events endpoint like Stripe's where the client can read everything that would have been sent. That way the client can replay all the events at leisure and retries aren't the server's responsibility.