Чтобы позволить пользователям API проверять подлинность исходящих вебхуков, я использую модель, аналогичную Slack:

• Конкатенировать временную метку и тело, HMAC с предустановленным ключом, добавить временную метку и HMAC дайджест в заголовки.

• Получатель делает то же самое и сравнивает с дайджестом в заголовке.

Я могу реализовать это исключительно для исходящих вебхуков или могу реализовать это как промежуточное ПО, которое выполняет этот процесс как для исходящих вебхуков, так и для ответов на запросы.

Является ли последний вариант хорошей практикой? Хорошей идеей?

Это плохая идея.

Вы фактически (зло)употребляете симметричной криптографией для реализации асимметричной криптографии. В вашем подходе возникнут следующие проблемы:

• Если у вас есть только один ключ, то каждый клиент, которому вы передадите ключ, может эффективно выдавать себя за вас
• Если у вас есть один ключ на клиента, вам необходимо заботиться о генерации ключей, хранении, обмене, устаревании и т.д.

Гораздо лучшая идея заключалась бы в использовании любой асимметричной криптографической системы (эллиптические кривые, RSA и т.д.). Схема будет работать следующим образом:

• Вы генерируете пару приватного и публичного ключей и распространяете публичный ключ.
• Вы подписываете временную метку и тело, а затем отправляете это вашим клиентам.
• Клиенты используют ваш публичный ключ для проверки подписи, и таким образом подлинности и целостности сообщения.

Предполагая, что вы используете HTTPS (или другой протокол, защищенный TLS или аналогичной безопасностью), вам не нужно подписывать ответы. Цель подписи — защитить целостность сообщения (что уже обеспечивается TLS) и аутентифицировать отправителя сообщения (что также уже обеспечивается TLS). Имеет смысл подписывать запросы, потому что по умолчанию HTTPS аутентифицирует только сервер (сторону, которая получает запросы и отправляет ответы).

Вот почему, когда вы входит в Google или аналогичный сервис, вы предоставляете свои учетные данные (имя пользователя + пароль + любые дополнительные факторы), но сервер не обязан добавлять никакую подпись к своим ответам, которую вам затем необходимо проверить. Аутентификация сервера осуществляется на уровне TLS, между вашим браузером (или другим клиентом) и их сервером.

Аутентификация клиента в HTTPS возможна и будет существенно более безопасной, чем схема подписания, которую вы используете в настоящее время. Это известно как “взаимный TLS” (или просто “mTLS”) или “TLS с клиентскими сертификатами”, и требует, чтобы клиент (в данном случае, ваше программное обеспечение, генерирующее вызовы вебхуков; даже если вы рассматриваете это как “сервер”, это клиент для целей этих запросов) аутентифицировался на серверах пользователей с использованием своего сертификата. Серверы пользователя должны быть настроены на ожидание этого сертификата, что поддерживает почти все серверные программные обеспечения, но иногда это бывает непросто настроить. Тем не менее, это обеспечивает лучшую защиту, чем описанная вами система, без необходимости в том, чтобы другая сторона могла выдать себя за вас, или чтобы у вас был уникальный предустановленный ключ для каждого пользователя.