To allow api users to verify the authenticity of outgoing webhooks, I am using a similar model to slack:

  • Concatenate timestamp and body, HMAC with pre-shared key, add timestamp and HMAC digest to headers.

  • Recipient does the same, and compares to the digest in the header.

I can either implement this exclusively on outgoing webhooks, or I can implement it as middleware that performs this process on both outgoing webhooks, and responses to requests.

Is doing the latter good practice? A good idea?


This is a bad idea.

You are essentially (ab)using symmetric cryptography to implement asymmetric cryptography. In your approach, the following problems will arise:

  • If you only have one key, then every client you distribute the key to can effectively impersonate you
  • If you have one key per client, you need to worry about key generation, storage, exchange, deprecation, etc.

A much better idea would be to use any asymmetric cipher (Elliptic Curves, RSA, etc.). The scheme would then work as follows:

  • You generate a private and public key pair, and distribute the public key.
  • You sign the timestamp and body, then send it off to your client(s).
  • The client(s) use your public key to verify the signature, and thus both the authenticity and integrity of the message.
  • I would use one key per client, but I only have three clients. From the reading that I’ve done, HMAC always seems to be done with symmetric keys, and slack seems to use it for their outgoing web hooks. Have I misunderstood that process?
    – Alex
    Jan 24 '20 at 10:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.