Webhook callback security

Question

I provide a web Service to Customers. I want to provide a feature where upon some event I will notify the Customer by sending a request to a Customer-provided URL.

For example, a notification of order shipment might be sent via a GET request https://customer.example.com/order/12345?status=shipped

How can the Customer trust this request to be authentic?

When the Customer receives this request they need to verify that the request is really from the Service, it has not been tampered with, and is private.

Sending to the Customer only over SSL comes to mind, but requires the Customer to run an SSL-enabled web server with a signed certificate. Plus, to authenticate the Service (the client in this request) requires a client-side certificate. But, SSL should handle encryption, man-in-the-middle, message signing, and replay attacks.

The IP address of the Service can change, so of no use for authentication.

Another approach is used by PayPal's IPN system. PayPal sends a notification to the Customer (merchant in this example) and then the Customer sends the payload back to PayPal over SSL for confirmation. Essentially asking: "Hey, PayPal. Did you send this to me?"

Can you think of any other approaches?

Answer 1

Even if you sign the message with a private/public key pair, you'll need to implement something to prevent replay attacks.

Perhaps a better way would be to just notify them that they have something new, then have them hit your server to get the new thing. They can then simply poll your server and verify your SSL certificate.

You'll need to authenticate them on your side before you send them any data.

For the notification, you could simply post to them the a signed date and time of the latest notification. This way, even if that notification is replayed, they'll know since the time and date won't be newer than the last one.