Hacker News Reader

Comment by paulddraper | Hacker News Reader

I think you are confused.

In either case the server authenticates with TLS and PKI.

But for APIs, the client (usually) authorizes with tokens. And for webhooks, the client (usually) authorizes with signed requests.

---

You could just as easily imagine API authorization with signed requests (e.g. AWS). Or webhook authorization with tokens (e.g. JIRA can do this).

Or where either one uses mTLS (e.g. CMS HETS).

That's not how it's usually done.

But the client-server requirements for confidentiality and authenticity are the same. The only difference is who is the "client" and who is the "server."

View on HN

It seems you were correct that I was confused. This comment didn't help me discover that but this[0] one in combination with rereading did.

In that context, you're right that I was more confused than now but I disagree that the client-server requirements for confidentiality and authenticity are the same.

In the case of webhooks the sender does not want to include breach of the receiver in their threat model. The consequences of and ability to detect malicious API calls to service are different than those of malicious calls claiming to be from a service. A shared secret removes the potential for detection from the service while asynchronous key signing does not.

[0] https://news.ycombinator.com/item?id=44108512

> A shared secret removes the potential for detection from the service while asynchronous key signing does not.

I would approximate that 95% of the time when a webhook sender discusses signatures they are referring to HMAC (symmetric-key signing). There is a clear benefit to asymmetric-key signatures but that's not the focus of this article. It's discussing the industry convention of using symmetric-key signing.

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.

Yes, I agree.

Reply on news.ycombinator.com