[rkeene2]

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 doesn't make a lot of sense, I do either:

- A shared secret

- A signed and HMACed payload with asymmetric key

[rkeene2]

Although this ONLY holds if you're using HTTPS -- which is a separate thing, so maybe they're considering that you might not use HTTPS.

[js2]

In my case I'm using mTLS and verifying the CN of the client cert. This is for an internal service. I'm also surprised the recommended headers doesn't include the event type. I found it beneficial to be able route the event before parsing the body and w/o having to use different endpoints.