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

# Nastavení integrace Okta

> Propojte Okta se službou Living Security pro správu životního cyklu uživatelů, autentizaci, MFA a administrativní aktivitu.

export const PublicIntegrationNextSteps = () => <>
    <hr />
    <h2>Související zdroje</h2>
    <ul>
      <li>
        <a href="/cs/signals/data-sources">Zjistěte, jak se data z integrací mění na signály pro řízení lidských rizik</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/integrations">Prozkoumejte integrace společnosti Living Security</a>
      </li>
      <li>
        <a href="https://app.livingsecurity.ai/">Otevřete Living Security Platform</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/request-demo/">Požádejte o demo společnosti Living Security</a>
      </li>
    </ul>
  </>;

export const EgressIpSafelist = ({system}) => <Note>
    <strong>Přidejte na seznam povolených všechny čtyři odchozí IP adresy synchronizace Living Security</strong> v systému{' '}
    {system}. Pokud {system} očekává zápis CIDR, zadejte každou adresu jako jednotlivého hostitele s příponou <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 />
    Provoz může odcházet z kterékoli ze čtyř adres, takže povolení pouze některých z nich způsobuje občasná
    selhání synchronizace. Tyto čtyři adresy jsou stejné ve všech regionech Living Security. Úplný seznam, zásady změn a řešení potíží najdete v článku{' '}
    <a href="/cs/integrations/managing/egress-ip-addresses">
      Konfigurace odchozích IP adres integrace
    </a>.
  </Note>;

export const ConnectInPlatform = ({tile, children}) => <Step title="Zadejte přihlašovací údaje v Living Security Platform">
    <p>
      Tento krok provádí osoba s přístupem do Living Security – vlastník programu, nebo správce
      systému, pokud byl pozván (delegované nastavení).
    </p>
    <ol>
      <li>
        Přejděte do části <strong>Nastavení → Integrace → Katalog</strong>, najděte dlaždici{' '}
        <strong>{tile}</strong> a klikněte na <strong>Připojení</strong>.
      </li>
      <li>
        Vyplňte níže uvedená pole a poté klikněte na <strong>Připojení</strong>.
      </li>
    </ol>
    {children}
  </Step>;

## Přehled

Okta může poskytovat normalizovaná data o životním cyklu uživatelů, autentizaci, MFA a administrativní aktivitě. Mezi prověřené příklady patří:

* `account.locked` — účet byl uzamčen
* `mfa.factor.activated` — aktivuje další faktory MFA
* `auth.login.failed` — se nepodaří přihlásit

Obě metody připojení čtou stejné dva datové toky — adresář uživatelů (`/api/v1/users`) a systémový log (`/api/v1/logs`). Viz [jak se data z integrací mění na signály](/cs/signals/data-sources).

## Výběr metody připojení

| | **Okta (SSWS)** | **Okta (OAuth 2.0)** |
| - | - | - |
| Přihlašovací údaje | Token API, který vytvoříte v konzoli Admin Console | ID klienta a privátní JWK, který vygenerujete a zaregistrujete |
| Nastavení | Tři kroky, bez generování klíčového materiálu | Devět kroků, včetně páru klíčů RSA |
| Požadovaná role správce | Správce s oprávněním pouze pro čtení, přiřazená vlastníkovi tokenu | Správce s oprávněním pouze pro čtení, přiřazená aplikaci |
| Platnost tokenu | Deaktivuje se po 30 dnech nepoužívání | Bez expirace; rotace páru klíčů je ve vaší správě |
| Kdy metodu použít | Doporučená volba pro většinu organizací | Vaše bezpečnostní politika zakazuje dlouhodobě platné tokeny API |

Obě metody vyžadují stejný přístup, takže volba se týká správy přihlašovacích údajů, nikoli toho, co platforma může číst.

***

## Varianta A — token API (SSWS)

*Doporučeno.*

### Co Living Security potřebuje

| Přihlašovací údaj | Popis |
| - | - |
| **Klíč API** | Token API služby Okta. V dialogu připojení je toto pole označeno jako **Klíč API** |
| **Subdoména tenanta** | `<tenant>` v `<tenant>.okta.com` — pouze samotná subdoména, nikoli celá adresa URL |

### Předpoklady

* Abyste mohli vytvořit uživatele servisního účtu, přiřadit role správce a vytvářet tokeny API, musíte být v Okta **Super Administrator**.

<Steps>
  <Step title="Vytvoření uživatele, který bude token vlastnit">
    Token API služby Okta má oprávnění uživatele, který jej vytvořil, a přestane fungovat, pokud je tento uživatel deaktivován. Vytvořte proto vyhrazený servisní účet místo osobního administrátorského účtu, aby připojení přežilo personální změny.

    1. V konzoli Admin Console přejděte do **Directory** → **People**.
    2. Klikněte na **Add person** a vytvořte uživatele, například `svc-livingsecurity@yourcompany.com`.
    3. Aktivujte účet.
  </Step>

  <Step title="Přiřazení role správce s oprávněním pouze pro čtení">
    Platforma pouze čte. Udělení širších oprávnění než pro čtení by tokenu poskytlo oprávnění, která nikdy nevyužije.

    1. Přejděte do **Zabezpečení** → **Administrators**.
    2. Klikněte na **Add administrator** a vyberte uživatele z předchozího kroku.
    3. Přiřaďte roli **Read-only Administrator**.
    4. Uložte.

    <Note>
      Bez role správce volání rozhraní Okta Management API proběhnou úspěšně s odpovědí `200 OK` a vrátí prázdný seznam. Neexistuje žádné `403`, které by vás upozornilo na chybějící roli — datové toky zůstanou prostě prázdné.
    </Note>
  </Step>

  <Step title="Vytvoření tokenu API">
    1. Přihlaste se do konzole Admin Console **jako uživatel servisního účtu** z kroku 1. Token zdědí oprávnění účtu, který jej vytvoří.
    2. Přejděte do **Zabezpečení** → **API** a otevřete kartu **Tokens**.
    3. Klikněte na **Create token**, zadejte název, například `Living Security Platform`, a klikněte na **Create token**.
    4. Hodnotu tokenu nyní zkopírujte — Okta ji zobrazí pouze jednou a už nikdy více.

    <Warning>
      Okta deaktivuje token API po **30 dnech nepoužívání**. Synchronizace v této integraci probíhají nejméně jednou denně, takže aktivní připojení udržuje svůj token naživu. Připojení, které zůstane pozastavené měsíc, bude vyžadovat nový token.
    </Warning>

    <EgressIpSafelist system="Okta" />

    <Note>
      Výše uvedený seznam adres je důležitý pouze v případě, že vaše organizace Okta omezuje přístup k API pomocí **síťové zóny**. Většina organizací to nedělá.
    </Note>
  </Step>

  <Step title="Zjištění subdomény tenanta">
    Adresa URL vaší konzole Admin Console vypadá takto: `https://acme-admin.okta.com`. Subdoména tenanta je `acme` — bez přípony `-admin`, bez `.okta.com` a bez `https://`.
  </Step>

  <ConnectInPlatform tile="Okta (SSWS)">
    | Pole | Hodnota |
    | - | - |
    | **Klíč API** | Token API z kroku 3 |
    | **Subdoména tenanta** | Subdoména z kroku 4 (např. `acme`) |
  </ConnectInPlatform>
</Steps>

Nyní jste připojeni k Okta (SSWS).

### Řešení potíží

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    Token je neplatný, byl zrušen nebo byl deaktivován po 30 dnech nečinnosti. Vytvořte nový token jako uživatel servisního účtu a znovu jej zadejte v připojení.
  </Accordion>

  <Accordion title="Připojeno, ale všechny datové toky jsou prázdné">
    Vlastník tokenu nemá žádnou roli správce. Přiřaďte servisnímu účtu roli **Read-only Administrator** (krok 2) — pokud role chybí, API místo chyby vrací `200 OK` s prázdným seznamem.
  </Accordion>

  <Accordion title="Synchronizace selhávají po personální změně">
    Token přestane fungovat, pokud je deaktivován uživatel, který jej vytvořil. Proto by měl token patřit servisnímu účtu, nikoli konkrétní osobě.
  </Accordion>
</AccordionGroup>

***

## Varianta B — servisní aplikace OAuth 2.0

Tuto metodu použijte, pokud vaše bezpečnostní politika nepovoluje dlouhodobě platné tokeny API. Token nahrazuje ID klienta a pár klíčů RSA, který vlastníte. V platformě jde o dlaždici **Okta (OAuth 2.0)** v části **Nastavení → Integrace → Katalog**.

Pro autentizaci v Okta pomocí Client Credentials potřebujete následující:

1. **ID klienta** – jedinečný identifikátor vaší aplikace Okta API Services.
2. **Privátní klíč (JWK)** – privátní klíč RSA ve formátu JSON Web Key, jehož veřejný klíč je zaregistrován ve vaší aplikaci Okta.
3. **Doména Okta** – pouze subdoména vašeho tenanta Okta (např. `dev-12345678`), nikoli celý název hostitele.
4. **Rozsahy (scopes)** – seznam rozsahů rozhraní Okta Management API oddělených mezerou (např. `okta.users.read okta.logs.read`).

Tento návod vás provede vytvořením aplikace API Services v Okta s autentizací `private_key_jwt`.

### Předpoklady:

* Musíte mít účet Okta. Bezplatný vývojářský účet si můžete zřídit na [developer.okta.com](https://developer.okta.com/signup/).

#### Krok 1: Vytvoření aplikace Okta API Services

1. Přihlaste se do [konzole Okta Admin Console](https://login.okta.com/).
2. V levém postranním panelu přejděte na **Applications** > **Applications**.
3. Klikněte na **Create App Integration**.
4. Jako metodu přihlášení vyberte **API Services** a klikněte na **Další**.

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

5. Zadejte název aplikace a klikněte na **Uložit**.
6. Na kartě **General** aplikace najděte své **ID klienta** — budete ho potřebovat v posledním kroku.
7. Nastavte Client authentication na **Public key / Private key**. Rozsahy `okta.*` jsou podporovány pouze s touto metodou autentizace.

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

8. Zakažte **Proof of possession (DPoP)** — není podporováno.

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

<Note>
  Aplikace musí být vytvořena jako **API Services**.
</Note>

#### Krok 2: Vygenerování a registrace páru klíčů RSA

##### Použití generátoru klíčů Okta

Okta může pár klíčů RSA vygenerovat přímo v konzoli Admin Console:

1. V konzoli Admin Console otevřete svou aplikaci API Services.
2. Přejděte na kartu **General** a sjeďte do sekce **PUBLIC KEYS**.
3. Klikněte na **Add Key** a poté vyberte **Generate new key**.
4. Klikněte na **Uložit** — Okta vygeneruje pár klíčů a jednorázově zobrazí **Privátní klíč (JWK)**.
5. Okamžitě zkopírujte a uložte JSON privátního klíče — znovu se již nezobrazí.

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

6. Veřejný klíč se automaticky zaregistruje ve vaší aplikaci.

<Note>
  Zkopírujte privátní JWK dříve, než dialog zavřete. V posledním kroku jej vložte do pole **Privátní klíč** v Living Security Platform.
</Note>

##### Vytvoření vlastního klíče

Okta pro aplikace API Services používá `private_key_jwt`. Vygenerujete pár klíčů RSA, **veřejný** JWK zaregistrujete v Okta a **privátní** JWK poskytnete platformě Living Security Platform.

**Vygenerujte privátní JWK** pomocí následujícího skriptu Node.js (vyžaduje 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));
```

**Zaregistrujte veřejný JWK v Okta:**

1. V konzoli Admin Console otevřete svou aplikaci API Services.
2. Přejděte na kartu **General** a sjeďte do sekce **PUBLIC KEYS**.
3. Klikněte na **Add Key**, vložte **JSON veřejného JWK** z výstupu výše uvedeného skriptu a klikněte na **Uložit**.

<Note>
  Do Living Security Platform vkládáte privátní JWK. Obsahuje veškerý klíčový materiál (`d`, `p`, `q`, `dp`, `dq`, `qi`) a `kid`. Uchovávejte jej v tajnosti.
</Note>

#### Krok 3: Zjištění domény Okta

Zadejte pouze subdoménu svého tenanta Okta — část před `.okta.com`.

* V konzoli Admin Console se v adresním řádku prohlížeče zobrazí adresa URL podobná `https://dev-12345678-admin.okta.com`.
* Vaše **doména Okta** je pouze subdoména (např. `dev-12345678`), nikoli `dev-12345678.okta.com`.
* Případně přejděte v konzoli Admin Console do **Nastavení** > **Account**, kde doménu Okta najdete, a poté použijte část se subdoménou.

#### Krok 4: Udělení rozsahů API vaší aplikaci

Okta vyžaduje alespoň jeden rozsah v každém požadavku na token. Než si vaše aplikace bude moci vyžádat konkrétní rozsahy, musí jí být uděleny:

1. V konzoli Admin Console přejděte na **Applications** > **Applications** a otevřete svou aplikaci.
2. Klikněte na kartu **Okta API Scopes**.
3. Udělte rozsahy, které vaše integrace vyžaduje: `okta.users.read` a `okta.logs.read`.

Úplný seznam dostupných rozsahů najdete v [referenční dokumentaci Okta Management API](https://developer.okta.com/docs/api/oauth2/#okta-admin-management).

#### Krok 5: Přiřazení role správce vaší aplikaci

Samotné udělení rozsahů nestačí — koncové body rozhraní Okta Management API (např. `/api/v1/users`) tiše vrátí prázdnou odpověď `200 []`, pokud aplikace nemá žádnou roli správce. Musíte přiřadit alespoň **Read-Only Administrator**:

1. V konzoli Admin Console přejděte na **Zabezpečení** > **Administrators** (nebo na **Applications** > **Applications** > vaše aplikace > **Admin roles**).
2. Klikněte na **Add administrator assignment** a vyberte svou aplikaci API Services.

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

3. Přiřaďte roli **Read-Only Administrator** (nebo vyšší, podle potřebných rozsahů).
4. Klikněte na **Uložit**.

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

<Note>
  Bez role správce volání API proběhnou úspěšně s odpovědí `200 OK`, ale vrátí prázdné výsledky a neexistuje žádná chyba `403`, která by na problém upozornila.
</Note>

#### Krok 6: Zadání přihlašovacích údajů v Living Security Platform

Jakmile máte své **ID klienta**, **Privátní klíč (JWK)**, **Doménu Okta** a **Rozsahy**:

1. Otevřete formulář, ve kterém se potřebujete autentizovat v Okta (Client Credentials).
2. Zadejte své **ID klienta**.
3. Vložte svůj **Privátní klíč (JWK)** — celý objekt JSON ze skriptu výše (jednořádkový nebo formátovaný).
4. Zadejte svou **Doménu Okta** pouze jako subdoménu tenanta (např. `dev-12345678`).
5. Zadejte **Rozsahy** jako seznam oddělený mezerami (např. `okta.users.read okta.logs.read`).
6. Formulář odešlete a autentizace by měla proběhnout úspěšně.

Nyní jste připojeni k Okta (Client Credentials).

***

<Note>Části této dokumentace jsou převzaty a upraveny z [Nango](https://nango.dev/docs/) a používány na základě [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.