Skip to main content
Для використання Public API OAuth не потрібен. Для приватної серверної інтеграції почніть з API-ключа з обмеженою областю дії та виконайте кроки з короткого посібника. Обирайте облікові дані клієнта OAuth, якщо політика безпеки вашої організації вимагає короткострокових токенів доступу або ваша платформа інтеграції вже підтримує цей потік. Обидва варіанти використовують службовий обліковий запис. Службовий обліковий запис — це ідентичність інтеграції, а не третій метод автентифікації.

​
Як поєднуються складники

Створюйте один службовий обліковий запис для кожної інтеграції. Оберіть для цього облікового запису API-ключ або клієнт OAuth; обидва методи в кожному запиті до API не потрібні. Жодні облікові дані не можуть перевищувати поточні дозволи облікового запису. У короткому посібнику використовується Basic-автентифікація. Для API-ключів також підтримується заголовок Bearer; використання цього заголовка не означає, що вам потрібен клієнт 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 або дозволи, потрібні для операції.