For the complete documentation index, see llms.txt. This page is also available as Markdown.

Webhook Security for Advocate Programs

Webhook requests originating from your Advocate program are signed so that you can confirm that the request is legitimate. Signatures are specific to every webhook, allowing you to confirm that the message was not intercepted in a man-in-the-middle attack.

All Advocate webhooks include two signatures that can be used to verify authenticity.

Signature
Description

X-Hook-JWS-RFC-7797 (Recommended)

A JSON Web Signature (JWS) that supports key rotation, signed using the Advocate JSON Web Key Set (JWKS). It is asymmetrically signed.

X-Hook-Signature

A HMAC-SHA1 hash of the hook's body contents, signed by your API key. Note: X-Hook-Signature uses HMAC-SHA1, which is considered a weak hashing algorithm by modern security standards. For this reason, we recommend using X-Hook-JWS-RFC-7797 for webhook verification, as it provides stronger security through asymmetric signing and supports key rotation.

Although you can verify the webhook's authenticity via the signature, you may still need to verify the state of the data by making an API call.


Verify a webhook payload

  1. Confirm that the X-Hook-JWS-RFC-7797 header exists. If it doesn't exist, then the request didn't come from impact.com.

  2. Look up the public keys of the Advocate JWKS. There should be a kid that matches the header of the JWS.

  1. Get the JSON body from the request.

  2. Use a JWT library for your programming language to verify that the body matches the signature. The JWS signature uses a detached payload, so it is of the form JWSHEADER..JWSSIGNATURE.

To implement the verification, some languages may require you to Base64 encode the JWS payload (e.g. the webhook body) in order to verify the JWS. Note that vanilla Base64 does not work in this context. The JWT standard requires each part of a JWT to be encoded using the URL variant of Base64 encoding without padding. These libraries support RFC-7797 and JWKS, and simplify verifying a JWS:

Validation code examples

Below are code examples of validating the JWS of a webhook request.

Verify the webhook's IP address

Your Advocate program sends webhooks from one of the following IP Addresses. You can rely on this list for adding additional security, but we still recommend validation via JWS as your primary security mechanism.


Reference

Signature generation process

The X-Hook-JWS-RFC-7797 signature is a JWS with a detached payload. It is a string that looks like JWSHeader..JWSSignature.

The signature generation works as follows:

  1. Webhook data is generated.

    • Example: A reward.created webhook.

  2. The payload is signed using one of the keys from our JWS key set.

    • Example: kid: 94ab304d-c90a-45ba-80e4-b4516a57a1c8

  3. The JWS header will contain some standard properties:

    • kid: The key used to sign the request. This can be looked up in the JWKS.

    • alg: RS256

    • typ: JWT

  4. The JWS is added as the X-Hook-JWS-RFC-7797 header to the webhook request.

  5. The HTTP Request is sent as a POST to all the webhook endpoints subscribed.

Cryptography standards

JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. The JWS cryptographic mechanisms provide integrity protection for an arbitrary sequence of octets.

JSON Web Token (JWT) is a a compact, URL-safe means of representing claims to be transferred between two parties. Essentially, it is a JWS structure with a JSON object as the payload, enabling the claims to be digitally signed, MACed, or encrypted.

JSON Web Key Set (JWKS) is a standard for sharing crytographic keys. Our JWKS contains the public keys of the public/private key pairs used for asymmetric encryption. That means that it is signed with a private key known only to impact.com, but that the signature can be verified by anyone using the matching public key from the JWKS.

Sample webhook content

Last updated