> ## 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.

# Konfiguracja integracji z Okta

> Połącz Okta z Living Security, aby uzyskać dane o cyklu życia użytkowników, uwierzytelnianiu, MFA i aktywności administracyjnej.

export const PublicIntegrationNextSteps = () => <>
    <hr />
    <h2>Powiązane zasoby</h2>
    <ul>
      <li>
        <a href="/pl/signals/data-sources">Dowiedz się, w jaki sposób dane z integracji stają się sygnałami w ramach zarządzania ryzykiem związanym z czynnikiem ludzkim (Human Risk Management)</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/integrations">Poznaj integracje Living Security</a>
      </li>
      <li>
        <a href="https://app.livingsecurity.ai/">Otwórz Living Security Platform</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/request-demo/">Poproś o demonstrację Living Security</a>
      </li>
    </ul>
  </>;

export const EgressIpSafelist = ({system}) => <Note>
    <strong>Dodaj wszystkie cztery adresy IP ruchu wychodzącego synchronizacji Living Security</strong> do listy dozwolonych w{' '}
    {system}. Jeśli {system} oczekuje notacji CIDR, wprowadź każdy adres jako pojedynczego hosta z sufiksem <code>/32</code>:
    <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 />
    Ruch może wychodzić z dowolnego z tych czterech adresów, dlatego dodanie do listy dozwolonych tylko niektórych z nich powoduje sporadyczne błędy synchronizacji. Te cztery adresy są takie same we wszystkich regionach Living Security. Pełną listę, zasady wprowadzania zmian oraz wskazówki dotyczące rozwiązywania problemów znajdziesz w artykule{' '}
    <a href="/pl/integrations/managing/egress-ip-addresses">
      Konfigurowanie adresów IP ruchu wychodzącego integracji
    </a>.
  </Note>;

export const ConnectInPlatform = ({tile, children}) => <Step title="Wprowadź dane uwierzytelniające w Living Security Platform">
    <p>
      Czynność wykonuje osoba posiadająca dostęp do Living Security — właściciel programu lub
      administrator systemu, jeśli został zaproszony (konfiguracja delegowana).
    </p>
    <ol>
      <li>
        Przejdź do <strong>Ustawienia → Integracje → Katalog</strong>, znajdź kafelek{' '}
        <strong>{tile}</strong> i kliknij <strong>Połącz</strong>.
      </li>
      <li>
        Wypełnij poniższe pola, a następnie kliknij <strong>Połącz</strong>.
      </li>
    </ol>
    {children}
  </Step>;

## Omówienie

Okta może dostarczać znormalizowane dane o cyklu życia użytkowników, uwierzytelnianiu, MFA i aktywności administracyjnej. Sprawdzone przykłady obejmują:

* `account.locked` — konto zostało zablokowane
* `mfa.factor.activated` — aktywuje dodatkowe czynniki MFA
* `auth.login.failed` — nie może się zalogować

Obie metody połączenia odczytują te same dwa strumienie — katalog użytkowników (`/api/v1/users`) oraz dziennik systemowy (`/api/v1/logs`). Zobacz [jak dane z integracji stają się sygnałami](/pl/signals/data-sources).

## Wybór metody połączenia

| | **Okta (SSWS)** | **Okta (OAuth 2.0)** |
| - | - | - |
| Poświadczenia | Token API tworzony w konsoli administracyjnej (Admin Console) | Identyfikator klienta oraz prywatny klucz JWK, które samodzielnie generujesz i rejestrujesz |
| Konfiguracja | Trzy kroki, bez generowania materiału kluczowego | Dziewięć kroków, w tym para kluczy RSA |
| Wymagana rola administratora | Administrator tylko do odczytu, przypisany do właściciela tokenu | Administrator tylko do odczytu, przypisany do aplikacji |
| Okres ważności tokenu | Jest dezaktywowany po 30 dniach bez użycia | Bez wygaśnięcia; rotacja pary kluczy należy do Ciebie |
| Kiedy wybrać | Zalecana ścieżka dla większości organizacji | Polityka bezpieczeństwa zabrania używania długoterminowych tokenów API |

Obie metody wymagają tego samego dostępu, więc wybór dotyczy sposobu obsługi poświadczeń, a nie tego, co platforma może odczytać.

***

## Opcja A — token API (SSWS)

*Zalecana.*

### Czego potrzebuje Living Security

| Poświadczenie | Opis |
| - | - |
| **Klucz API** | Token API Okta. W oknie połączenia to pole ma etykietę **Klucz API** |
| **Subdomena dzierżawy** | `<tenant>` w `<tenant>.okta.com` — sama subdomena, a nie pełny adres URL |

### Wymagania wstępne

* Musisz mieć w Okta rolę **Super Administrator**, aby utworzyć użytkownika konta usługi, przypisać role administratora i tworzyć tokeny API.

<Steps>
  <Step title="Utwórz użytkownika, który będzie właścicielem tokenu">
    Token API Okta ma uprawnienia użytkownika, który go utworzył, i przestaje działać, jeśli ten użytkownik zostanie dezaktywowany. Utwórz dedykowane konto usługi zamiast używać osobistego konta administratora, aby połączenie przetrwało zmiany kadrowe.

    1. W konsoli administracyjnej (Admin Console) przejdź do **Directory** → **People**.
    2. Kliknij **Add person** i utwórz użytkownika, na przykład `svc-livingsecurity@yourcompany.com`.
    3. Aktywuj konto.
  </Step>

  <Step title="Przypisz rolę administratora tylko do odczytu">
    Platforma wyłącznie odczytuje dane. Przyznanie uprawnień wykraczających poza odczyt nadaje tokenowi uprawnienia, z których nigdy nie korzysta.

    1. Przejdź do **Security** → **Administrators**.
    2. Kliknij **Add administrator** i wybierz użytkownika z poprzedniego kroku.
    3. Przypisz rolę **Read-only Administrator**.
    4. Zapisz.

    <Note>
      Bez roli administratora wywołania Okta Management API kończą się powodzeniem z kodem `200 OK` i zwracają pustą listę. Nie ma `403` informującego o braku roli — strumienie po prostu pozostają puste.
    </Note>
  </Step>

  <Step title="Utwórz token API">
    1. Zaloguj się do konsoli administracyjnej (Admin Console) **jako użytkownik konta usługi** z kroku 1. Token dziedziczy uprawnienia konta, które go tworzy.
    2. Przejdź do **Security** → **API** i otwórz kartę **Tokens**.
    3. Kliknij **Create token**, nadaj mu nazwę, na przykład `Living Security Platform`, a następnie kliknij **Create token**.
    4. Skopiuj wartość tokenu teraz — Okta wyświetla ją tylko raz.

    <Warning>
      Okta dezaktywuje token API po **30 dniach bez użycia**. Synchronizacje w tej integracji są uruchamiane co najmniej raz dziennie, więc aktywne połączenie utrzymuje ważność własnego tokenu. Połączenie wstrzymane na miesiąc wymaga nowego tokenu.
    </Warning>

    <EgressIpSafelist system="Okta" />

    <Note>
      Powyższa lista adresów ma znaczenie tylko wtedy, gdy Twoja organizacja Okta ogranicza dostęp do API za pomocą **stref sieciowych (network zones)**. Większość organizacji tego nie robi.
    </Note>
  </Step>

  <Step title="Znajdź subdomenę dzierżawy">
    Adres URL Twojej konsoli administracyjnej wygląda jak `https://acme-admin.okta.com`. Subdomena dzierżawy to `acme` — bez sufiksu `-admin`, bez `.okta.com` i bez `https://`.
  </Step>

  <ConnectInPlatform tile="Okta (SSWS)">
    | Pole | Wartość |
    | - | - |
    | **Klucz API** | Token API z kroku 3 |
    | **Subdomena dzierżawy** | Subdomena z kroku 4 (np. `acme`) |
  </ConnectInPlatform>
</Steps>

Połączenie z Okta (SSWS) zostało skonfigurowane.

### Rozwiązywanie problemów

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    Token jest nieprawidłowy, został unieważniony lub został dezaktywowany po 30 dniach braku aktywności. Utwórz nowy token jako użytkownik konta usługi i wprowadź go ponownie w połączeniu.
  </Accordion>

  <Accordion title="Połączono, ale wszystkie strumienie są puste">
    Właściciel tokenu nie ma roli administratora. Przypisz kontu usługi rolę **Read-only Administrator** (krok 2) — gdy brakuje roli, API zwraca `200 OK` z pustą listą zamiast błędu.
  </Accordion>

  <Accordion title="Synchronizacje kończą się błędem po zmianie kadrowej">
    Token przestaje działać, jeśli użytkownik, który go utworzył, zostanie dezaktywowany. Dlatego token powinien należeć do konta usługi, a nie do osoby.
  </Accordion>
</AccordionGroup>

***

## Opcja B — aplikacja usługowa OAuth 2.0

Użyj tej metody, jeśli Twoja polityka bezpieczeństwa nie zezwala na długoterminowe tokeny API. Zastępuje ona token identyfikatorem klienta i parą kluczy RSA, których jesteś właścicielem. W platformie jest to kafelek **Okta (OAuth 2.0)** w sekcji **Ustawienia → Integracje → Katalog**.

Aby uwierzytelnić się w Okta za pomocą Client Credentials, potrzebujesz następujących elementów:

1. **Identyfikator klienta** — unikalny identyfikator Twojej aplikacji Okta API Services.
2. **Klucz prywatny (JWK)** — prywatny klucz RSA w formacie JSON Web Key, którego klucz publiczny jest zarejestrowany w Twojej aplikacji Okta.
3. **Domena Okta** — wyłącznie subdomena Twojej dzierżawy Okta (np. `dev-12345678`), a nie pełna nazwa hosta.
4. **Zakresy (Scopes)** — lista zakresów Okta Management API oddzielonych spacjami (np. `okta.users.read okta.logs.read`).

Ten przewodnik przeprowadzi Cię przez tworzenie aplikacji API Services w Okta z uwierzytelnianiem `private_key_jwt`.

### Wymagania wstępne:

* Musisz mieć konto Okta. Możesz zarejestrować bezpłatne konto deweloperskie na stronie [developer.okta.com](https://developer.okta.com/signup/).

#### Krok 1: Tworzenie aplikacji Okta API Services

1. Zaloguj się do [konsoli administracyjnej Okta (Okta Admin Console)](https://login.okta.com/).
2. W lewym pasku bocznym przejdź do **Applications** > **Applications**.
3. Kliknij **Create App Integration**.
4. Jako metodę logowania wybierz **API Services** i kliknij **Dalej**.

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

5. Nadaj aplikacji nazwę i kliknij **Zapisz**.
6. Na karcie **General** aplikacji znajdź swój **Identyfikator klienta** — będzie potrzebny w ostatnim kroku.
7. Ustaw opcję Client authentication na **Public key / Private key**. Zakresy `okta.*` są obsługiwane wyłącznie przy tej metodzie uwierzytelniania.

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

8. Wyłącz **Proof of possession (DPoP)** — ta funkcja nie jest obsługiwana.

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

<Note>
  Aplikacja musi zostać utworzona jako **API Services**.
</Note>

#### Krok 2: Generowanie i rejestrowanie pary kluczy RSA

##### Użyj generatora kluczy Okta

Okta może wygenerować parę kluczy RSA bezpośrednio w konsoli administracyjnej (Admin Console):

1. W konsoli administracyjnej otwórz swoją aplikację API Services.
2. Przejdź na kartę **General** i przewiń do sekcji **PUBLIC KEYS**.
3. Kliknij **Add Key**, a następnie wybierz **Generate new key**.
4. Kliknij **Zapisz** — Okta generuje parę kluczy i jednorazowo wyświetla **klucz prywatny (JWK)**.
5. Natychmiast skopiuj i zapisz kod JSON klucza prywatnego — nie zostanie wyświetlony ponownie.

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

6. Klucz publiczny jest automatycznie rejestrowany w Twojej aplikacji.

<Note>
  Skopiuj prywatny klucz JWK przed zamknięciem okna dialogowego. Wklej go w ostatnim kroku do pola **Klucz prywatny** w Living Security Platform.
</Note>

##### Utwórz własny klucz

Okta używa `private_key_jwt` dla aplikacji API Services. Generujesz parę kluczy RSA, rejestrujesz w Okta **publiczny** klucz JWK i przekazujesz **prywatny** klucz JWK do Living Security Platform.

**Wygeneruj prywatny klucz JWK** za pomocą poniższego skryptu Node.js (wymagany 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));
```

**Zarejestruj publiczny klucz JWK w Okta:**

1. W konsoli administracyjnej otwórz swoją aplikację API Services.
2. Przejdź na kartę **General** i przewiń do sekcji **PUBLIC KEYS**.
3. Kliknij **Add Key**, wklej **kod JSON publicznego klucza JWK** wygenerowany przez powyższy skrypt i kliknij **Zapisz**.

<Note>
  Do Living Security Platform wklejasz prywatny klucz JWK. Zawiera on cały materiał kluczowy (`d`, `p`, `q`, `dp`, `dq`, `qi`) oraz `kid`. Zachowaj go w tajemnicy.
</Note>

#### Krok 3: Znajdowanie domeny Okta

Wprowadź wyłącznie subdomenę swojej dzierżawy Okta — część przed `.okta.com`.

* W konsoli administracyjnej pasek adresu przeglądarki wyświetli adres URL podobny do `https://dev-12345678-admin.okta.com`.
* Twoja **Domena Okta** to wyłącznie subdomena (np. `dev-12345678`), a nie `dev-12345678.okta.com`.
* Możesz też przejść w konsoli administracyjnej do **Ustawienia** > **Account**, aby znaleźć swoją domenę Okta, a następnie użyć jej części będącej subdomeną.

#### Krok 4: Przyznawanie zakresów API aplikacji

Okta wymaga co najmniej jednego zakresu w każdym żądaniu tokenu. Zanim aplikacja będzie mogła żądać określonych zakresów, muszą one zostać przyznane:

1. W konsoli administracyjnej przejdź do **Applications** > **Applications** i otwórz swoją aplikację.
2. Kliknij kartę **Okta API Scopes**.
3. Przyznaj zakresy wymagane przez integrację: `okta.users.read` i `okta.logs.read`.

Pełną listę dostępnych zakresów znajdziesz w [dokumentacji Okta Management API](https://developer.okta.com/docs/api/oauth2/#okta-admin-management).

#### Krok 5: Przypisywanie roli administratora do aplikacji

Samo przyznanie zakresów nie wystarcza — punkty końcowe Okta Management API (np. `/api/v1/users`) po cichu zwracają pustą odpowiedź `200 []`, jeśli aplikacja nie ma roli administratora. Musisz przypisać co najmniej **Read-Only Administrator**:

1. W konsoli administracyjnej przejdź do **Security** > **Administrators** (lub do **Applications** > **Applications** > Twoja aplikacja > **Admin roles**).
2. Kliknij **Add administrator assignment** i wybierz swoją aplikację API Services.

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

3. Przypisz rolę **Read-Only Administrator** (lub wyższą, w zależności od potrzebnych zakresów).
4. Kliknij **Zapisz**.

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

<Note>
  Bez roli administratora wywołania API kończą się powodzeniem z kodem `200 OK`, ale zwracają puste wyniki, a błąd `403` nie informuje o problemie.
</Note>

#### Krok 6: Wprowadzanie poświadczeń w Living Security Platform

Gdy masz już swój **Identyfikator klienta**, **Klucz prywatny (JWK)**, **Domenę Okta** i **Zakresy**:

1. Otwórz formularz, w którym chcesz uwierzytelnić się w Okta (Client Credentials).
2. Wprowadź swój **Identyfikator klienta**.
3. Wklej swój **Klucz prywatny (JWK)** — pełny obiekt JSON ze skryptu powyżej (w jednym wierszu lub sformatowany).
4. Wprowadź swoją **Domenę Okta** jako samą subdomenę dzierżawy (np. `dev-12345678`).
5. Wprowadź **Zakresy** jako listę oddzieloną spacjami (np. `okta.users.read okta.logs.read`).
6. Prześlij formularz, a uwierzytelnianie powinno zakończyć się powodzeniem.

Połączenie z Okta (Client Credentials) zostało skonfigurowane.

***

<Note>Fragmenty tej dokumentacji zostały zaadaptowane z [Nango](https://nango.dev/docs/) i są używane na podstawie [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.