I recognize all this. Of course different mechanisms of authentication can be used in APIs. There is also of course a swap in who plays server and client when hitting a company's API vs receiving a webhook request from that same company.
The key difference isn't with the mechanism of authentication (although that is different) but who specifies, implements, and maintains the authentication. Webhook providers do a lot of work to avoid putting that on their clients and to keep centralized control over their implementation.
The API producer will always retain ownership over the authentication mechanism.
The article is comparing the use of a shared secret vs HMAC.
For shared secret: Who specifies auth? The webhook producer. Who implements auth? The webhook consumer. For HMAC / signing it's exactly the same parties who do those things.
Discussions about mutual TLS and public keys are out of scope.
I think the webhook producer tends to implement auth in both scenarios but agree that the webhook consumer executes auth in the webhook case. You perhaps meant this but I was initially confused by what you were trying to say here. You other comment was far more helpful, thank you for making it.
In summary of my other comment, it is the case that the implementation and execution roles are the same but the threat surface is very different.
> but who specifies, implements, and maintains the authentication. Webhook providers do a lot of work to avoid putting that on their clients and to keep centralized control over their implementation.
The key difference isn't with the mechanism of authentication (although that is different) but who specifies, implements, and maintains the authentication. Webhook providers do a lot of work to avoid putting that on their clients and to keep centralized control over their implementation.