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

# Az Okta integráció beállítása

> Csatlakoztassa az Okta rendszert a Living Security rendszerhez a felhasználói életciklus, a hitelesítés, az MFA és az adminisztratív tevékenység adatainak fogadásához.

export const PublicIntegrationNextSteps = () => <>
    <hr />
    <h2>Kapcsolódó források</h2>
    <ul>
      <li>
        <a href="/hu/signals/data-sources">Ismerje meg, hogyan válnak az integrációs adatok a Human Risk Management jelzéseivé</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/integrations">Fedezze fel a Living Security integrációit</a>
      </li>
      <li>
        <a href="https://app.livingsecurity.ai/">Nyissa meg a Living Security Platformot</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/request-demo/">Kérjen demót a Living Security-tól</a>
      </li>
    </ul>
  </>;

export const EgressIpSafelist = ({system}) => <Note>
    <strong>Adja hozzá mind a négy Living Security szinkronizálási kimenő IP-címet</strong> a(z){' '}
    {system} engedélyezési listájához. Adja meg mindegyiket önálló hosztként <code>/32</code> előtaggal, ha a(z) {system} CIDR-jelölést vár:
    <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 />
    A forgalom bármelyik címről indulhat, ezért ha csak néhányat engedélyez, az időszakos szinkronizálási hibákat okoz. Ez a négy cím a Living Security minden régiójában azonos. A teljes listát, a módosítási szabályzatot és a hibaelhárítást lásd itt:{' '}
    <a href="/hu/integrations/managing/egress-ip-addresses">
      Integrációk kimenő IP-címeinek konfigurálása
    </a>.
  </Note>;

export const ConnectInPlatform = ({tile, children}) => <Step title="Adja meg a hitelesítő adatokat a Living Security Platformban">
    <p>
      A lépést az hajtja végre, aki rendelkezik Living Security-hozzáféréssel – a programgazda, vagy a
      rendszergazda, ha meghívták (delegált beállítás).
    </p>
    <ol>
      <li>
        Lépjen a <strong>Beállítások → Integrációk → Katalógus</strong> oldalra, keresse meg a{' '}
        <strong>{tile}</strong> csempét, majd kattintson a <strong>Csatlakozás</strong> gombra.
      </li>
      <li>
        Töltse ki az alábbi mezőket, majd kattintson a <strong>Csatlakozás</strong> gombra.
      </li>
    </ol>
    {children}
  </Step>;

## Áttekintés

Az Okta normalizált adatokkal járulhat hozzá a felhasználói életciklus, a hitelesítés, az MFA és az adminisztratív tevékenység területén. Az áttekintett példák a következők:

* `account.locked` — fiók zárolva
* `mfa.factor.activated` — további MFA-tényezőket aktivál
* `auth.login.failed` — a bejelentkezés sikertelen

Mindkét csatlakozási módszer ugyanazt a két adatfolyamot olvassa: a felhasználói címtárat (`/api/v1/users`) és a rendszernaplót (`/api/v1/logs`). Lásd: [hogyan válnak az integrációs adatokból jelzések](/hu/signals/data-sources).

## Csatlakozási módszer kiválasztása

| | **Okta (SSWS)** | **Okta (OAuth 2.0)** |
| - | - | - |
| Hitelesítő adat | Az Admin Console felületen létrehozott API-token | Ön által generált és regisztrált ügyfél-azonosító és privát JWK |
| Beállítás | Három lépés, kulcsanyagot nem kell generálni | Kilenc lépés, köztük egy RSA-kulcspár létrehozása |
| Szükséges rendszergazdai szerepkör | Csak olvasási jogú rendszergazda, a token tulajdonosához rendelve | Csak olvasási jogú rendszergazda, az alkalmazáshoz rendelve |
| Token élettartama | 30 nap használat nélkül inaktiválódik | Nem jár le; a kulcspár cseréje az Ön feladata |
| Mikor használja | Ez a legtöbb szervezet számára ajánlott megoldás | Biztonsági szabályzata tiltja a hosszú élettartamú API-tokenek használatát |

Mindkét módszerhez ugyanarra a hozzáférésre van szükség, ezért a választás a hitelesítő adatok kezelésére vonatkozik, nem arra, hogy a platform mit olvashat.

***

## A lehetőség — API-token (SSWS)

*Ajánlott.*

### A Living Security számára szükséges adatok

| Hitelesítő adat | Leírás |
| - | - |
| **API-kulcs** | Egy Okta API-token. A csatlakozási párbeszédpanel ezt a mezőt **API-kulcs** néven jeleníti meg |
| **Bérlői aldomain** | A `<tenant>` a `<tenant>.okta.com` címben — csak az aldomain, nem a teljes URL |

### Előfeltételek

* Az Okta **Super Administrator** szerepkörével kell rendelkeznie ahhoz, hogy szolgáltatásfiók-felhasználót hozzon létre, rendszergazdai szerepköröket rendeljen hozzá, és API-tokeneket hozzon létre.

<Steps>
  <Step title="Felhasználó létrehozása a token tulajdonosaként">
    Az Okta API-token annak a felhasználónak a jogosultságait hordozza, aki létrehozta, és leáll, ha ezt a felhasználót inaktiválják. Személyes rendszergazdai fiók helyett hozzon létre külön szolgáltatásfiókot, hogy a kapcsolat a személyi változásokat is túlélje.

    1. Az Admin Console felületen lépjen a **Directory** → **People** oldalra.
    2. Kattintson az **Add person** elemre, és hozzon létre egy felhasználót, például `svc-livingsecurity@yourcompany.com` néven.
    3. Aktiválja a fiókot.
  </Step>

  <Step title="A csak olvasási jogú rendszergazdai szerepkör hozzárendelése">
    A platform kizárólag olvas. Az olvasásnál szélesebb körű hozzáférés megadása olyan jogosultságokat adna a tokennek, amelyeket soha nem használ.

    1. Lépjen a **Security** → **Administrators** oldalra.
    2. Kattintson az **Add administrator** elemre, és válassza ki az előző lépésben létrehozott felhasználót.
    3. Rendelje hozzá a **Read-only Administrator** szerepkört.
    4. Save.

    <Note>
      Rendszergazdai szerepkör nélkül az Okta Management API hívásai `200 OK` válaszkóddal sikeresek, és üres listát adnak vissza. Nincs `403`, amely jelezné a szerepkör hiányát — az adatfolyamok egyszerűen üresek maradnak.
    </Note>
  </Step>

  <Step title="Az API-token létrehozása">
    1. Jelentkezzen be az Admin Console felületre **az 1. lépésben létrehozott szolgáltatásfiók-felhasználóként**. A token annak a fióknak a jogosultságait örökli, amelyik létrehozza.
    2. Lépjen a **Security** → **API** oldalra, és nyissa meg a **Tokens** lapot.
    3. Kattintson a **Create token** elemre, adjon neki nevet, például `Living Security Platform`, majd kattintson a **Create token** elemre.
    4. Másolja ki a token értékét most — az Okta csak egyszer jeleníti meg.

    <Warning>
      Az Okta **30 nap használat nélkül** inaktivál egy API-tokent. Az integráció szinkronizálásai legalább naponta egyszer lefutnak, ezért az aktív kapcsolat életben tartja a saját tokenjét. Az egy hónapig szüneteltetett kapcsolathoz új token szükséges.
    </Warning>

    <EgressIpSafelist system="Okta" />

    <Note>
      A fenti címlista csak akkor számít, ha az Okta-szervezete **hálózati zónák** alapján korlátozza az API-hozzáférést. A legtöbb szervezet nem így tesz.
    </Note>
  </Step>

  <Step title="A bérlői aldomain megkeresése">
    Az Admin Console URL-je így néz ki: `https://acme-admin.okta.com`. A bérlői aldomain a `acme` — a `-admin` utótag, a `.okta.com` és a `https://` nélkül.
  </Step>

  <ConnectInPlatform tile="Okta (SSWS)">
    | Mező | Érték |
    | - | - |
    | **API-kulcs** | A 3. lépésben létrehozott API-token |
    | **Bérlői aldomain** | A 4. lépésben megtalált aldomain (pl. `acme`) |
  </ConnectInPlatform>
</Steps>

Ezzel csatlakozott az Okta (SSWS) szolgáltatáshoz.

### Hibaelhárítás

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    A token érvénytelen, visszavonták, vagy 30 nap inaktivitás után inaktiválták. Hozzon létre új tokent a szolgáltatásfiók-felhasználóként, és adja meg újra a kapcsolaton.
  </Accordion>

  <Accordion title="A kapcsolat létrejött, de minden adatfolyam üres">
    A token tulajdonosának nincs rendszergazdai szerepköre. Rendelje hozzá a **Read-only Administrator** szerepkört a szolgáltatásfiókhoz (2. lépés) — ha a szerepkör hiányzik, az API hiba helyett `200 OK` választ ad üres listával.
  </Accordion>

  <Accordion title="A szinkronizálás személyi változás után sikertelen">
    A token leáll, ha a létrehozó felhasználót inaktiválják. Ezért a tokennek szolgáltatásfiókhoz kell tartoznia, nem természetes személyhez.
  </Accordion>
</AccordionGroup>

***

## B lehetőség — OAuth 2.0 szolgáltatásalkalmazás

Akkor használja ezt a módszert, ha a biztonsági szabályzata nem engedélyezi a hosszú élettartamú API-tokeneket. A tokent egy ügyfél-azonosítóval és egy Ön által birtokolt RSA-kulcspárral váltja fel. A platformon ez az **Okta (OAuth 2.0)** csempe a **beállítások → integrációk → katalógus** alatt.

Az Okta Client Credentials használatával történő hitelesítéshez a következőkre van szükség:

1. **Ügyfél-azonosító** - Az Okta API Services alkalmazás egyedi azonosítója.
2. **Privát kulcs (JWK)** - A JSON Web Key formátumú RSA privát kulcs, amelynek nyilvános kulcsa regisztrálva van az Okta alkalmazásban.
3. **Okta-tartomány** - Csak az Okta-bérlő aldomainje (pl. `dev-12345678`), nem a teljes hosztnév.
4. **Hatókörök** - Az Okta Management API hatóköreinek szóközzel elválasztott listája (pl. `okta.users.read okta.logs.read`).

Ez az útmutató végigvezeti egy API Services alkalmazás létrehozásán az Oktában `private_key_jwt` hitelesítéssel.

### Előfeltételek:

* Rendelkeznie kell Okta-fiókkal. Ingyenes fejlesztői fiókra a [developer.okta.com](https://developer.okta.com/signup/) oldalon regisztrálhat.

#### 1. lépés: Az Okta API Services alkalmazás létrehozása

1. Jelentkezzen be az [Okta Admin Console](https://login.okta.com/) felületre.
2. A bal oldali sávban lépjen az **Applications** > **Applications** oldalra.
3. Kattintson a **Create App Integration** elemre.
4. Bejelentkezési módként válassza az **API Services** lehetőséget, majd kattintson a **Next** elemre.

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

5. Adjon nevet az alkalmazásnak, majd kattintson a **Save** elemre.
6. Az alkalmazás **General** lapján keresse meg a **Client ID** értéket — az utolsó lépésben szüksége lesz rá.
7. A Client authentication beállításnál válassza a **Public key / Private key** lehetőséget. A `okta.*` hatókörök csak ezzel a hitelesítési móddal támogatottak.

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

8. Tiltsa le a **Proof of possession (DPoP)** beállítást — nem támogatott.

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

<Note>
  Az alkalmazást **API Services** típusúként kell létrehozni.
</Note>

#### 2. lépés: Az RSA-kulcspár generálása és regisztrálása

##### Az Okta kulcsgenerátorának használata

Az Okta közvetlenül az Admin Console felületen is létre tudja hozni az RSA-kulcspárt:

1. Az Admin Console felületen nyissa meg az API Services alkalmazást.
2. Lépjen a **General** lapra, és görgessen a **PUBLIC KEYS** szakaszhoz.
3. Kattintson az **Add Key** elemre, majd válassza a **Generate new key** lehetőséget.
4. Kattintson a **Save** elemre — az Okta létrehozza a kulcspárt, és egyszer megjeleníti a **Private Key (JWK)** értéket.
5. Azonnal másolja ki és mentse el a privát kulcs JSON-ját — nem jelenik meg újra.

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

6. A nyilvános kulcs automatikusan regisztrálódik az alkalmazásban.

<Note>
  A párbeszédpanel bezárása előtt másolja ki a privát JWK-t. Az utolsó lépésben illessze be a Living Security Platform **Privát kulcs** mezőjébe.
</Note>

##### Saját kulcs létrehozása

Az Okta API Services alkalmazásokhoz `private_key_jwt` használ. Létrehoz egy RSA-kulcspárt, regisztrálja a **nyilvános** JWK-t az Oktában, a **privát** JWK-t pedig megadja a Living Security Platformnak.

**Privát JWK generálása** az alábbi Node.js szkripttel (Node.js 18+ szükséges):

```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));
```

**A nyilvános JWK regisztrálása az Oktában:**

1. Az Admin Console felületen nyissa meg az API Services alkalmazást.
2. Lépjen a **General** lapra, és görgessen a **PUBLIC KEYS** szakaszhoz.
3. Kattintson az **Add Key** elemre, illessze be a fenti szkript által kiadott **nyilvános JWK JSON-t**, majd kattintson a **Save** elemre.

<Note>
  A privát JWK-t kell beillesztenie a Living Security Platformba. Tartalmazza az összes kulcsanyagot (`d`, `p`, `q`, `dp`, `dq`, `qi`) és a `kid` értéket. Tartsa titokban.
</Note>

#### 3. lépés: Az Okta-tartomány megkeresése

Csak az Okta-bérlő aldomainjét adja meg — a `.okta.com` előtti részt.

* Az Admin Console felületen a böngésző címsorában egy ilyen URL látható: `https://dev-12345678-admin.okta.com`.
* Az **Okta-tartomány** csak az aldomain (pl. `dev-12345678`), nem a `dev-12345678.okta.com`.
* Másik lehetőségként az Admin Console felületen lépjen a **Settings** > **Account** oldalra, ahol megtalálja az Okta-tartományt, majd használja az aldomain részt.

#### 4. lépés: API-hatókörök megadása az alkalmazásnak

Az Okta minden tokenkérésben legalább egy hatókört megkövetel. Mielőtt az alkalmazás adott hatóköröket kérhetne, azokat meg kell adni:

1. Az Admin Console felületen lépjen az **Applications** > **Applications** oldalra, és nyissa meg az alkalmazást.
2. Kattintson az **Okta API Scopes** lapra.
3. Adja meg az integrációhoz szükséges hatóköröket: `okta.users.read` és `okta.logs.read`.

Az elérhető hatókörök teljes listája az [Okta Management API referenciában](https://developer.okta.com/docs/api/oauth2/#okta-admin-management) található.

#### 5. lépés: Rendszergazdai szerepkör hozzárendelése az alkalmazáshoz

A hatókörök megadása önmagában nem elegendő — az Okta Management API végpontjai (pl. `/api/v1/users`) néma módon üres `200 []` választ adnak, ha az alkalmazásnak nincs rendszergazdai szerepköre. Legalább a **Read-Only Administrator** szerepkört hozzá kell rendelnie:

1. Az Admin Console felületen lépjen a **Security** > **Administrators** oldalra (vagy az **Applications** > **Applications** > az Ön alkalmazása > **Admin roles** oldalra).
2. Kattintson az **Add administrator assignment** elemre, és válassza ki az API Services alkalmazást.

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

3. Rendelje hozzá a **Read-Only Administrator** szerepkört (vagy magasabbat, a szükséges hatóköröktől függően).
4. Kattintson a **Save** elemre.

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

<Note>
  Rendszergazdai szerepkör nélkül az API-hívások `200 OK` válaszkóddal sikeresek, de üres eredményt adnak, és nincs `403` hiba, amely jelezné a problémát.
</Note>

#### 6. lépés: Hitelesítő adatok megadása a Living Security Platformban

Ha már rendelkezik az **ügyfél-azonosítóval**, a **privát kulccsal (JWK)**, az **Okta-tartománnyal** és a **hatókörökkel**:

1. Nyissa meg az űrlapot, amelyen az Okta (Client Credentials) hitelesítést el kell végeznie.
2. Adja meg az **ügyfél-azonosítót**.
3. Illessze be a **privát kulcsot (JWK)** — a fenti szkript által kiadott teljes JSON-objektumot (egysoros vagy formázott alakban).
4. Adja meg az **Okta-tartományt** csak bérlői aldomainként (pl. `dev-12345678`).
5. Adja meg a **hatóköröket** szóközzel elválasztott listaként (pl. `okta.users.read okta.logs.read`).
6. Küldje el az űrlapot, és a hitelesítésnek sikeresnek kell lennie.

Ezzel csatlakozott az Okta (Client Credentials) szolgáltatáshoz.

***

<Note>A dokumentáció egyes részei a [Nango](https://nango.dev/docs/) anyagából készült adaptációk, az [Elastic License 2.0](https://github.com/NangoHQ/nango?tab=License-1-ov-file#readme) feltételei szerint felhasználva.</Note>

<PublicIntegrationNextSteps />


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