> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Налаштування інтеграції з Okta

> Підключіть Okta до Living Security для отримання даних про життєвий цикл користувачів, автентифікацію, MFA та адміністративну активність.

export const PublicIntegrationNextSteps = () => <>
    <hr />
    <h2>Пов’язані ресурси</h2>
    <ul>
      <li>
        <a href="/uk/signals/data-sources">Дізнайтеся, як дані інтеграцій перетворюються на сигнали Human Risk Management</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/integrations">Ознайомтеся з інтеграціями Living Security</a>
      </li>
      <li>
        <a href="https://app.livingsecurity.ai/">Відкрийте Living Security Platform</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/request-demo/">Замовте демонстрацію Living Security</a>
      </li>
    </ul>
  </>;

export const EgressIpSafelist = ({system}) => <Note>
    <strong>Додайте всі чотири вихідні IP-адреси синхронізації Living Security</strong> до списку дозволених у{' '}
    {system}. Вводьте кожну адресу як окремий вузол із суфіксом <code>/32</code>, якщо {system} очікує нотацію CIDR:
    <br />
    <code>52.34.139.153/32</code>, <code>54.69.127.183/32</code>, <code>44.247.133.183/32</code>,{' '}
    <code>52.26.211.56/32</code>
    <br />
    <br />
    Трафік може надходити з будь-якої з цих чотирьох адрес, тому додавання до списку дозволених лише частини з них спричиняє періодичні збої синхронізації. Ці чотири адреси однакові в усіх регіонах Living Security. Повний перелік, політику змін і усунення несправностей див. у статті{' '}
    <a href="/uk/integrations/managing/egress-ip-addresses">
      Configuring Integration Egress IP Addresses
    </a>.
  </Note>;

export const ConnectInPlatform = ({tile, children}) => <Step title="Введіть облікові дані в Living Security Platform">
    <p>
      Виконується особою, яка має доступ до Living Security, — власником програми або
      системним адміністратором, якщо його було запрошено (делеговане налаштування).
    </p>
    <ol>
      <li>
        Перейдіть до <strong>Settings → Integrations → Catalog</strong>, знайдіть плитку{' '}
        <strong>{tile}</strong> і натисніть <strong>Connect</strong>.
      </li>
      <li>
        Заповніть наведені нижче поля, а потім натисніть <strong>Connect</strong>.
      </li>
    </ol>
    {children}
  </Step>;

## Огляд

Okta може надавати нормалізовані дані про життєвий цикл користувачів, автентифікацію, MFA та адміністративну активність. Серед перевірених прикладів:

* `account.locked` — обліковий запис заблоковано
* `mfa.factor.activated` — активує додаткові фактори MFA
* `auth.login.failed` — не вдається увійти

Обидва способи підключення зчитують одні й ті самі два потоки — каталог користувачів (`/api/v1/users`) та системний журнал (`/api/v1/logs`). Див. [як дані інтеграцій перетворюються на Signals](/uk/signals/data-sources).

## Вибір способу підключення

| | **Okta (SSWS)** | **Okta (OAuth 2.0)** |
| - | - | - |
| Облікові дані | API-токен, який ви створюєте в Admin Console | Ідентифікатор клієнта (client ID) і приватний JWK, які ви генеруєте та реєструєте |
| Налаштування | Три кроки, без генерації ключового матеріалу | Дев’ять кроків, зокрема створення пари ключів RSA |
| Потрібна роль адміністратора | Адміністратор лише для читання, призначений власнику токена | Адміністратор лише для читання, призначений застосунку |
| Термін дії токена | Деактивується після 30 днів невикористання | Без терміну дії; ротацію пари ключів виконуєте ви |
| Коли використовувати | Рекомендований варіант для більшості організацій | Ваша політика безпеки забороняє довготривалі API-токени |

Обидва способи потребують однакового доступу, тож вибір стосується лише поводження з обліковими даними, а не того, що платформа може зчитувати.

***

## Варіант A — API-токен (SSWS)

*Рекомендовано.*

### Що потрібно для Living Security

| Облікові дані | Опис |
| - | - |
| **API key** | API-токен Okta. У діалоговому вікні підключення це поле має назву **API key** |
| **Tenant subdomain** | `<tenant>` у `<tenant>.okta.com` — лише піддомен, а не повна URL-адреса |

### Передумови

* Щоб створити користувача службового облікового запису, призначити ролі адміністратора та створити API-токени, ви повинні мати роль **Super Administrator** в Okta.

<Steps>
  <Step title="Створіть користувача — власника токена">
    API-токен Okta має права користувача, який його створив, і перестає працювати, якщо цього користувача деактивовано. Створіть окремий службовий обліковий запис замість особистого облікового запису адміністратора, щоб підключення працювало попри кадрові зміни.

    1. В Admin Console перейдіть до **Directory** → **People**.
    2. Натисніть **Add person** і створіть користувача, наприклад `svc-livingsecurity@yourcompany.com`.
    3. Активуйте обліковий запис.
  </Step>

  <Step title="Призначте роль адміністратора лише для читання">
    Платформа лише зчитує дані. Надання прав, ширших за читання, наділяє токен дозволами, які він ніколи не використовує.

    1. Перейдіть до **Security** → **Administrators**.
    2. Натисніть **Add administrator** і виберіть користувача з попереднього кроку.
    3. Призначте роль **Read-only Administrator**.
    4. Збережіть зміни.

    <Note>
      Без ролі адміністратора виклики Okta Management API виконуються успішно з `200 OK` і повертають порожній список. Жодної `403`, яка б повідомила про відсутність ролі, не буде — потоки просто залишаються порожніми.
    </Note>
  </Step>

  <Step title="Створіть API-токен">
    1. Увійдіть в Admin Console **як користувач службового облікового запису** з кроку 1. Токен успадковує права того облікового запису, який його створює.
    2. Перейдіть до **Security** → **API** і відкрийте вкладку **Tokens**.
    3. Натисніть **Create token**, вкажіть назву, наприклад `Living Security Platform`, і натисніть **Create token**.
    4. Скопіюйте значення токена зараз — Okta показує його лише один раз.

    <Warning>
      Okta деактивує API-токен після **30 днів невикористання**. Синхронізації в цій інтеграції виконуються щонайменше раз на день, тож активне підключення підтримує чинність власного токена. Для підключення, яке залишалося призупиненим протягом місяця, потрібен новий токен.
    </Warning>

    <EgressIpSafelist system="Okta" />

    <Note>
      Наведений вище список адрес важливий, лише якщо ваша організація Okta обмежує доступ до API за **network zone**. Більшість організацій цього не роблять.
    </Note>
  </Step>

  <Step title="Визначте піддомен вашого тенанта">
    URL-адреса вашої Admin Console має вигляд `https://acme-admin.okta.com`. Піддомен тенанта — це `acme` — без суфікса `-admin`, без `.okta.com` і без `https://`.
  </Step>

  <ConnectInPlatform tile="Okta (SSWS)">
    | Поле | Значення |
    | - | - |
    | **API key** | API-токен із кроку 3 |
    | **Tenant subdomain** | Піддомен із кроку 4 (наприклад, `acme`) |
  </ConnectInPlatform>
</Steps>

Тепер підключення до Okta (SSWS) виконано.

### Усунення несправностей

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    Токен недійсний, був відкликаний або деактивований після 30 днів бездіяльності. Створіть новий токен від імені користувача службового облікового запису та введіть його в підключенні повторно.
  </Accordion>

  <Accordion title="Підключено, але всі потоки порожні">
    Власник токена не має ролі адміністратора. Призначте службовому обліковому запису роль **Read-only Administrator** (крок 2) — за відсутності ролі API повертає `200 OK` з порожнім списком замість помилки.
  </Accordion>

  <Accordion title="Синхронізації завершуються помилкою після кадрових змін">
    Токен перестає працювати, якщо користувача, який його створив, деактивовано. Саме тому токен має належати службовому обліковому запису, а не конкретній особі.
  </Accordion>
</AccordionGroup>

***

## Варіант B — службовий застосунок OAuth 2.0

Використовуйте цей спосіб, якщо ваша політика безпеки не дозволяє довготривалі API-токени. Він замінює токен на ідентифікатор клієнта та пару ключів RSA, якою володієте ви. На платформі це плитка **Okta (OAuth 2.0)** у розділі **Settings → Integrations → Catalog**.

Щоб автентифікуватися в Okta за допомогою Client Credentials, вам потрібно таке:

1. **Client ID** — унікальний ідентифікатор вашого застосунку Okta API Services.
2. **Private Key (JWK)** — приватний ключ RSA у форматі JSON Web Key, відкритий ключ якого зареєстровано у вашому застосунку Okta.
3. **Okta Domain** — лише піддомен вашого тенанта Okta (наприклад, `dev-12345678`), а не повне ім’я хоста.
4. **Scopes** — розділений пробілами список областей доступу (scopes) Okta Management API (наприклад, `okta.users.read okta.logs.read`).

Цей посібник проведе вас через створення застосунку API Services в Okta з автентифікацією `private_key_jwt`.

### Передумови:

* Ви повинні мати обліковий запис Okta. Зареєструйте безкоштовний обліковий запис розробника на [developer.okta.com](https://developer.okta.com/signup/).

#### Крок 1: Створення застосунку Okta API Services

1. Увійдіть до [Okta Admin Console](https://login.okta.com/).
2. На бічній панелі ліворуч перейдіть до **Applications** > **Applications**.
3. Натисніть **Create App Integration**.
4. Виберіть **API Services** як метод входу та натисніть **Next**.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/select-api-service.png" style={{maxWidth: "550px"}} />

5. Вкажіть назву застосунку та натисніть **Save**.
6. На вкладці **General** застосунку знайдіть свій **Client ID** — він знадобиться на завершальному кроці.
7. Встановіть для Client authentication значення **Public key / Private key**. Області доступу `okta.*` підтримуються лише з цим методом автентифікації.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/select-public-private-key.png" style={{maxWidth: "550px"}} />

8. Вимкніть **Proof of possession (DPoP)** — він не підтримується.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/disable-dpop.png" style={{maxWidth: "550px"}} />

<Note>
  Застосунок має бути створений як **API Services**.
</Note>

#### Крок 2: Генерація та реєстрація пари ключів RSA

##### Використання генератора ключів Okta

Okta може згенерувати пару ключів RSA безпосередньо в Admin Console:

1. В Admin Console відкрийте свій застосунок API Services.
2. Перейдіть на вкладку **General** і прокрутіть до розділу **PUBLIC KEYS**.
3. Натисніть **Add Key**, а потім виберіть **Generate new key**.
4. Натисніть **Save** — Okta згенерує пару ключів і один раз покаже **Private Key (JWK)**.
5. Негайно скопіюйте та збережіть JSON приватного ключа — повторно його показано не буде.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/create-public-key.png" style={{maxWidth: "550px"}} />

6. Відкритий ключ автоматично реєструється у вашому застосунку.

<Note>
  Скопіюйте приватний JWK, перш ніж закривати діалогове вікно. На завершальному кроці вставте його в поле **Private Key** у Living Security Platform.
</Note>

##### Створення власного ключа

Okta використовує `private_key_jwt` для застосунків API Services. Ви генеруєте пару ключів RSA, реєструєте **відкритий** JWK в Okta і надаєте **приватний** JWK для Living Security Platform.

**Згенеруйте приватний JWK** за допомогою наведеного нижче скрипта Node.js (потрібен Node.js 18+):

```javascript theme={null}
const { generateKeyPairSync } = require('crypto');
const { privateKey, publicKey } = generateKeyPairSync('rsa', { modulusLength: 2048 });

const privateJwk = privateKey.export({ format: 'jwk' });
const publicJwk  = publicKey.export({ format: 'jwk' });

// Assign a kid — must match between private and public JWK
const kid = require('crypto').randomUUID();
privateJwk.kid = kid;
publicJwk.kid  = kid;

console.log('=== PUBLIC JWK (upload to Okta) ===');
console.log(JSON.stringify(publicJwk, null, 2));
console.log('\n=== PRIVATE JWK (paste into the Living Security Platform) ===');
console.log(JSON.stringify(privateJwk));
```

**Зареєструйте відкритий JWK в Okta:**

1. В Admin Console відкрийте свій застосунок API Services.
2. Перейдіть на вкладку **General** і прокрутіть до розділу **PUBLIC KEYS**.
3. Натисніть **Add Key**, вставте **JSON відкритого JWK**, виведений наведеним вище скриптом, і натисніть **Save**.

<Note>
  Саме приватний JWK ви вставляєте в Living Security Platform. Він містить увесь ключовий матеріал (`d`, `p`, `q`, `dp`, `dq`, `qi`) і `kid`. Зберігайте його в таємниці.
</Note>

#### Крок 3: Визначення Okta Domain

Введіть лише піддомен вашого тенанта Okta — частину перед `.okta.com`.

* В Admin Console в адресному рядку браузера відображатиметься URL-адреса на кшталт `https://dev-12345678-admin.okta.com`.
* Ваш **Okta Domain** — це лише піддомен (наприклад, `dev-12345678`), а не `dev-12345678.okta.com`.
* Також можна перейти до **Settings** > **Account** в Admin Console, щоб знайти свій домен Okta, а потім використати частину з піддоменом.

#### Крок 4: Надання застосунку областей доступу API

Okta вимагає принаймні однієї області доступу в кожному запиті токена. Щоб ваш застосунок міг запитувати певні області доступу, їх потрібно спершу надати:

1. В Admin Console перейдіть до **Applications** > **Applications** і відкрийте свій застосунок.
2. Натисніть вкладку **Okta API Scopes**.
3. Надайте області доступу, потрібні вашій інтеграції: `okta.users.read` і `okta.logs.read`.

Повний список доступних областей доступу наведено в [довіднику Okta Management API](https://developer.okta.com/docs/api/oauth2/#okta-admin-management).

#### Крок 5: Призначення застосунку ролі адміністратора

Самого надання областей доступу недостатньо — кінцеві точки Okta Management API (наприклад, `/api/v1/users`) без жодних повідомлень повертають порожню відповідь `200 []`, якщо у вашого застосунку немає ролі адміністратора. Необхідно призначити принаймні **Read-Only Administrator**:

1. В Admin Console перейдіть до **Security** > **Administrators** (або до **Applications** > **Applications** > ваш застосунок > **Admin roles**).
2. Натисніть **Add administrator assignment** і виберіть свій застосунок API Services.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/admin-role-dropdown.png" style={{maxWidth: "550px"}} />

3. Призначте роль **Read-Only Administrator** (або вищу, залежно від потрібних вам областей доступу).
4. Натисніть **Save**.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/add-admin-role.png" style={{maxWidth: "550px"}} />

<Note>
  Без ролі адміністратора виклики API виконуються успішно з `200 OK`, але повертають порожні результати, а помилки `403`, яка б вказала на проблему, немає.
</Note>

#### Крок 6: Введення облікових даних у Living Security Platform

Коли у вас є **Client ID**, **Private Key (JWK)**, **Okta Domain** і **Scopes**:

1. Відкрийте форму, у якій потрібно автентифікуватися в Okta (Client Credentials).
2. Введіть свій **Client ID**.
3. Вставте свій **Private Key (JWK)** — повний об’єкт JSON зі скрипта вище (в один рядок або з форматуванням).
4. Введіть свій **Okta Domain** лише як піддомен тенанта (наприклад, `dev-12345678`).
5. Введіть **Scopes** у вигляді списку, розділеного пробілами (наприклад, `okta.users.read okta.logs.read`).
6. Надішліть форму, і автентифікація має завершитися успішно.

Тепер підключення до Okta (Client Credentials) виконано.

***

<Note>Окремі частини цієї документації адаптовано з [Nango](https://nango.dev/docs/) та використано за ліцензією [Elastic License 2.0](https://github.com/NangoHQ/nango?tab=License-1-ov-file#readme).</Note>

<PublicIntegrationNextSteps />


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.