Все коллекции
API и Webhooks
Webhooks
Webhooks. Настройка авторизации
Webhooks. Настройка авторизации
Mariia Lobchenko avatar
Автор: Mariia Lobchenko
Обновлено больше недели назад

Настройка авторизации для Webhooks нужна для обеспечения безопасности и подтверждения подлинности запросов, отправляемых на сервер.

Webhooks позволяют веб-приложениям получать автоматические уведомления от других веб-приложений, когда происходят определенные события. Однако, это также означает, что злоумышленники могут использовать Webhooks для отправки нежелательных запросов, которые могут повредить или нарушить работу сервера.

Настройка авторизации для Webhooks позволяет серверу проверить, что запросы приходят от доверенного источника, который имеет право отправлять эти запросы. Это достигается путем использования различных методов аутентификации и авторизации.

Существует несколько видов авторизаций для Webhooks, которые обеспечивают безопасность и защиту от нежелательных запросов.

Рассмотрим те, что доступны в нашей системе.


Basic Authentication.

Это метод аутентификации, который использует логин и пароль для проверки подлинности запросов. Веб-приложение должно отправлять логин и пароль в заголовке запроса, который затем проверяется на сервере.

Чтобы его активировать в разделе Webhooks при создании запроса достаточно выбрать тип Авторизации:

И заполнить логин и пароль, которые вы используете для доступа к сервису.

Затем, при каждом запросе на доступ к данным, отправляются запросы с указанием Base64-кодированных логина и пароля, и если данные запросы являются корректными, сервис выдаёт доступ к нужным данным.


OAuth 2.0.

Это стандартный протокол авторизации, который позволяет пользователям предоставлять доступ к своим ресурсам на сторонних веб-сайтах или приложениях без предоставления им своих учетных данных. OAuth использует токены доступа для обмена информацией между веб-приложениями.

Чтобы активировать данный тип авторизации аналогично в разделе Webhooks при создании запроса достаточно выбрать соответствующий тип Авторизации:

И заполнить следующие поля:

  • Имя токена - произвольное имя токена.

  • Callback URL - это URL-адрес, на который сервис отправляет ответ после завершения процедуры авторизации. Он используется для передачи токена доступа и других параметров, необходимых для дальнейшей работы с API.

Указанный вами Callback URL должен точно соответствовать адресу, который вы указали при регистрации приложения.

  • Auth URL - это URL-адрес, на который пользователь отправляется для начала процедуры авторизации в приложении или на сайте. На этой странице пользователь может ввести свои учетные данные и подтвердить согласие на доступ к своим данным в сервисе-провайдере.

  • Access token URL - это URL-адрес, который используется при процессе аутентификации для получения токена доступа к API. Когда приложение запрашивает доступ к защищенным ресурсам, оно предоставляет свой идентификатор и секретный ключ на сервере аутентификации, который возвращает токен доступа на Access token URL. Этот токен обычно имеет ограниченный срок действия и используется для авторизации запросов к API сервиса-провайдера.

  • Client ID (идентификатор клиента) - это уникальный идентификатор, который присваивается приложению при регистрации на сервисе-провайдере. Он используется для идентификации приложения при запросе доступа к API и получении токена доступа.

  • Client Secret (секретный ключ клиента) - это секретный ключ, который присваивается приложению при регистрации на сервисе-провайдере для использования его API. Он используется в сочетании с Client ID для аутентификации приложения и получения токена доступа.

  • Scope - это параметр, используемый при аутентификации для определения того, к каким ресурсам API приложение может получить доступ. Он указывается при запросе доступа к защищенным ресурсам и определяет уровень доступа приложения. Например, scope может указывать на доступ только к определенным типам данных или только на чтение данных, но не на запись.

  • В каком виде передать ключи доступа - при запросе на получение access_token сервис, на котором вы проходите авторизацию, может потребовать передачу client_secret в качестве параметра в теле запроса или в виде Basic заголовка. Ключ Рингостат тянет из вашей внешней системы.

Пример готового заполненного блока с авторизационными данными:


Нашли ответ на свой вопрос?