Skip to main content
Для использования Public API OAuth не требуется. Для закрытой серверной интеграции начните с ключа API с ограниченной областью действия и следуйте краткому руководству. Выбирайте учётные данные клиента OAuth (client credentials), если политика безопасности требует краткосрочных токенов доступа или ваша платформа интеграции уже поддерживает этот процесс. Оба варианта используют сервисную учётную запись. Сервисная учётная запись — это идентификатор интеграции, а не третий метод аутентификации.

​
Как связаны между собой компоненты

Создавайте по одной сервисной учётной записи для каждой интеграции. Для этой учётной записи выберите ключ API или клиент OAuth; оба метода одновременно в каждом запросе к API не нужны. Ни одни учётные данные не могут превышать текущие разрешения учётной записи. В кратком руководстве используется Basic-аутентификация. Заголовок Bearer также поддерживается для ключей API; использование этого заголовка не означает, что вам нужен клиент OAuth.

​
Выберите ключ API для простой интеграции

Используйте ключ API для собственных заданий по расписанию, скриптов отчётности, конвейеров данных или других серверных служб, если секрет, хранящийся в вашем менеджере секретов, соответствует вашим требованиям безопасности.
  • Выполняйте аутентифицированные запросы напрямую; обмен токенами не требуется.
  • Выбирайте только те разрешения, которые нужны рабочей нагрузке, и задавайте срок действия.
  • Выполняйте ротацию ключа в течение периода перекрытия или немедленно отзывайте его в случае компрометации.
Интеграции с ключом API клиент OAuth не требуется. Начните с краткого руководства, затем перейдите к разделу Ключи API, где описаны создание и ротация.

​
Выберите OAuth для краткосрочных токенов доступа

Используйте учётные данные клиента OAuth для конфиденциальной серверной службы, если ваша организация требует токены доступа с ограниченным сроком действия или инструмент интеграции ожидает тип разрешения client_credentials.
  1. Создайте клиент OAuth с ограниченной областью действия для сервисной учётной записи.
  2. Аутентифицируйте клиент на региональной конечной точке токенов с помощью метода аутентификации клиента, указанного при настройке.
  3. Отправляйте полученный токен доступа вместе с запросами к API. Получайте новый токен до истечения срока действия текущего.
OAuth добавляет в вашу интеграцию получение токенов и обработку истечения их срока действия. Секрет клиента по-прежнему требует безопасного хранения и ротации; краткосрочные токены не снимают эту ответственность. Учётные данные клиента не используют токены обновления: для получения нового токена доступа снова аутентифицируйте клиент. Доступ по OAuth должен быть включён для вашей организации. Если он не включён, используйте ключ API или обратитесь в службу поддержки Living Security, чтобы обсудить ваши требования. Сведения о создании клиента, одноразовых секретах, отзыве и восстановлении см. в разделе Учётные данные клиента OAuth.

​
Храните учётные данные на стороне серверной части

Ключи API сервисных учётных записей и секреты клиентов OAuth должны храниться в серверном хранилище секретов. Не размещайте их в коде браузера, мобильных приложениях, системе контроля версий или журналах. Учётные данные сервисной учётной записи действуют от имени рабочей нагрузки; они не выполняют вход пользователя и не обеспечивают процесс получения согласия клиента. В обоих случаях используйте региональный хост API вашей организации. Смена метода аутентификации не меняет URL ресурса, версию API или разрешения, необходимые для операции.