This document covered all of them. Here's the SSRF bit for example: https://github.com/standard-webhooks/standard-webhooks/blob/...
Why not have a dedicated event bus (could be - but not limited to - kafka, NATS etc.) where remote systems connect to dedicated event queues? Push a message onto the queue which is picked up by the remote system.
Authentication is handled by the event bus which can also act as a storage for message (re)delivery. Partitioned by customer ID for separation of concerns etc.
Anything immediately obvious why this wouldn't be a preferred option or is it because HTTP is just easier to implement across systems?
A webhook is "peer-to-peer" and uses the existing HTTP infrastructure that's already in your application. Whereas an event bus is "centralized" and requires a third service to run/maintain/design. I'd like to avoid that if possible.
Also webhooks make a lot of sense for communication between organizations, which you can't do with a centralized event bus (unless someone is out there running a global event bus that I'm not aware of). Let's say I'm using Managed Service Foo hosted by a third party, and I want to trigger some event in my own system whenever certain things happen in side Managed Service Foo. How else do you expect me to receive those events? Surely a webhook is a lot easier than figuring out an event bus to be shared across our two organizations.
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
Too loose to be a standard but better than nothing.
> Open source tools and guidelines for sending webhooks easily, securely and reliably
We have been going back and forth about this. Though we purposefully made Standard Webhooks more like guidelines than a formal specification (note there's no mention of RFC2119, for example) so that it's easier to conform to without forcing implementations to have breaking changes. Even if it means you don't get the full benefits.
I think people can get a lot of benefits even if they don't follow the whole thing, and it's our job to continue building tools to make it easier to build conforming implementations than non-conforming ones.
Edit: It seems to also have a header version. Not sure why there's two different ways to pass a signature here.
Isn't that basically a description of SSE (https://en.m.wikipedia.org/wiki/Server-sent_events)?
My point is that SSE is already a standard to do exactly the thing you're asking for: publish a one-way event stream, with a built-in mechanism for reconnecting and telling the remote end the last event you received (so you can catch up on anything missed during the disconnected period).
We have a lot of experience scaling those kinds of endpoints (and making them redundant) too.
Spinning up an always-on server that can maintain a persistent connection - and reconnect automatically if it drops, and if the server is rebooted with an update and suchlike - is a whole lot harder. Possible, but not nearly as easy.
I do think there's an argument for the interoperability of webhooks for integrating different services. I'm skeptical that they're the best choice from a purely technical perspective.