> ## 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-integratie instellen

> Verbind Okta met Living Security voor gebruikerslevenscyclus, authenticatie, MFA en beheerdersactiviteit.

export const PublicIntegrationNextSteps = () => <>
    <hr />
    <h2>Gerelateerde bronnen</h2>
    <ul>
      <li>
        <a href="/nl/signals/data-sources">Lees hoe integratiegegevens worden omgezet in Human Risk Management-signalen</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/integrations">Ontdek de integraties van Living Security</a>
      </li>
      <li>
        <a href="https://app.livingsecurity.ai/">Open het Living Security Platform</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/request-demo/">Vraag een demo van Living Security aan</a>
      </li>
    </ul>
  </>;

export const EgressIpSafelist = ({system}) => <Note>
    <strong>Voeg alle vier de uitgaande IP-adressen voor synchronisatie van Living Security toe</strong> aan de allowlist in{' '}
    {system}. Voer elk adres in als afzonderlijke host met <code>/32</code> als {system} CIDR-notatie verwacht:
    <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 />
    Het verkeer kan via elk van de vier adressen uitgaan. Als u slechts een deel ervan op de allowlist zet, leidt dat tot onregelmatige
    synchronisatiefouten. Deze vier adressen zijn in elke regio van Living Security gelijk. Zie{' '}
    <a href="/nl/integrations/managing/egress-ip-addresses">
      Uitgaande IP-adressen van Integraties configureren
    </a>{' '}
    voor de volledige lijst, het wijzigingsbeleid en probleemoplossing.
  </Note>;

export const ConnectInPlatform = ({tile, children}) => <Step title="Voer de inloggegevens in het Living Security Platform in">
    <p>
      Uit te voeren door degene die toegang heeft tot Living Security — de programma-eigenaar, of de
      systeembeheerder als deze is uitgenodigd (gedelegeerde installatie).
    </p>
    <ol>
      <li>
        Ga naar <strong>instellingen → Integraties → Catalog</strong>, zoek de tegel{' '}
        <strong>{tile}</strong> en klik op <strong>verbinden</strong>.
      </li>
      <li>
        Vul de onderstaande velden in en klik vervolgens op <strong>verbinden</strong>.
      </li>
    </ol>
    {children}
  </Step>;

## Overzicht

Okta kan genormaliseerde gegevens over de gebruikerslevenscyclus, authenticatie, MFA en beheerdersactiviteit aanleveren. Beoordeelde voorbeelden zijn onder andere:

* `account.locked` — account vergrendeld
* `mfa.factor.activated` — activeert extra MFA-factoren
* `auth.login.failed` — kan niet inloggen

Beide verbindingsmethoden lezen dezelfde twee streams: de gebruikersmap (`/api/v1/users`) en het systeemlogboek (`/api/v1/logs`). Zie [hoe integratiegegevens signalen worden](/nl/signals/data-sources).

## Kies een verbindingsmethode

| | **Okta (SSWS)** | **Okta (OAuth 2.0)** |
| - | - | - |
| Referentie | Een API-token dat u aanmaakt in de Admin Console | Een klant-ID en een privé-JWK die u genereert en registreert |
| Installatie | Drie stappen, geen sleutelmateriaal om te genereren | Negen stappen, inclusief een RSA-sleutelpaar |
| Vereiste beheerdersrol | Alleen-lezenbeheerder, toegewezen aan de eigenaar van het token | Alleen-lezenbeheerder, toegewezen aan de applicatie |
| Levensduur van het token | Wordt gedeactiveerd na 30 dagen zonder gebruik | Geen vervaldatum; het roteren van het sleutelpaar is uw verantwoordelijkheid |
| Gebruik deze methode wanneer | Dit is het aanbevolen pad voor de meeste organisaties | Uw beveiligingsbeleid langlevende API-tokens verbiedt |

Beide methoden vereisen dezelfde toegang, dus de keuze gaat over het beheer van referenties en niet over wat het platform kan lezen.

***

## Optie A — API-token (SSWS)

*Aanbevolen.*

### Wat Living Security nodig heeft

| Referentie | Beschrijving |
| - | - |
| **API-sleutel** | Een Okta API-token. In het verbindingsvenster heet dit veld **API-sleutel** |
| **Tenant-subdomein** | De `<tenant>` in `<tenant>.okta.com` — alleen het subdomein, niet de volledige URL |

### Vereisten

* U moet **Super Administrator** in Okta zijn om een serviceaccountgebruiker aan te maken, beheerdersrollen toe te wijzen en API-tokens aan te maken.

<Steps>
  <Step title="Maak een gebruiker aan die eigenaar van het token wordt">
    Een Okta API-token heeft de machtigingen van de gebruiker die het heeft aangemaakt en werkt niet meer als die gebruiker wordt gedeactiveerd. Maak daarom een speciaal serviceaccount aan in plaats van een persoonlijk beheerdersaccount te gebruiken, zodat de verbinding personeelswisselingen overleeft.

    1. Ga in de Admin Console naar **Directory** → **People**.
    2. Klik op **Add person** en maak een gebruiker aan, bijvoorbeeld `svc-livingsecurity@yourcompany.com`.
    3. Activeer het account.
  </Step>

  <Step title="Wijs de rol Alleen-lezenbeheerder toe">
    Het platform leest alleen. Als u meer dan leestoegang verleent, krijgt het token machtigingen die nooit worden gebruikt.

    1. Ga naar **Security** → **Administrators**.
    2. Klik op **Add administrator** en selecteer de gebruiker uit de vorige stap.
    3. Wijs de rol **Read-only Administrator** toe.
    4. Sla op.

    <Note>
      Zonder beheerdersrol slagen aanroepen van de Okta Management API met `200 OK` en leveren ze een lege lijst op. Er is geen `403` die aangeeft dat de rol ontbreekt — de streams blijven eenvoudig leeg.
    </Note>
  </Step>

  <Step title="Maak het API-token aan">
    1. Meld u aan bij de Admin Console **als de serviceaccountgebruiker** uit stap 1. Het token neemt de rechten over van het account dat het aanmaakt.
    2. Ga naar **Security** → **API** en open het tabblad **Tokens**.
    3. Klik op **Create token**, geef het een naam zoals `Living Security Platform` en klik op **Create token**.
    4. Kopieer nu de tokenwaarde — Okta toont deze slechts één keer en daarna nooit meer.

    <Warning>
      Okta deactiveert een API-token na **30 dagen zonder gebruik**. De synchronisaties in deze integratie draaien minimaal één keer per dag, zodat een actieve verbinding haar eigen token in leven houdt. Een verbinding die een maand gepauzeerd blijft, heeft een nieuw token nodig.
    </Warning>

    <EgressIpSafelist system="Okta" />

    <Note>
      De bovenstaande adreslijst is alleen van belang als uw Okta-org API-toegang beperkt via een **netwerkzone**. De meeste orgs doen dat niet.
    </Note>
  </Step>

  <Step title="Zoek uw tenant-subdomein">
    De URL van uw Admin Console ziet er als volgt uit: `https://acme-admin.okta.com`. Het tenant-subdomein is `acme` — zonder het achtervoegsel `-admin`, zonder `.okta.com` en zonder `https://`.
  </Step>

  <ConnectInPlatform tile="Okta (SSWS)">
    | Veld | Waarde |
    | - | - |
    | **API-sleutel** | Het API-token uit stap 3 |
    | **Tenant-subdomein** | Het subdomein uit stap 4 (bijv. `acme`) |
  </ConnectInPlatform>
</Steps>

U bent nu verbonden met Okta (SSWS).

### Probleemoplossing

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    Het token is ongeldig, is ingetrokken of is na 30 dagen inactiviteit gedeactiveerd. Maak als serviceaccountgebruiker een nieuw token aan en voer dit opnieuw in bij de verbinding.
  </Accordion>

  <Accordion title="Verbonden, maar alle streams zijn leeg">
    De eigenaar van het token heeft geen beheerdersrol. Wijs **Read-only Administrator** toe aan het serviceaccount (stap 2) — de API retourneert `200 OK` met een lege lijst in plaats van een foutmelding als de rol ontbreekt.
  </Accordion>

  <Accordion title="Synchronisaties mislukken na een personeelswijziging">
    Het token werkt niet meer als de gebruiker die het heeft aangemaakt wordt gedeactiveerd. Daarom moet het token eigendom zijn van een serviceaccount en niet van een persoon.
  </Accordion>
</AccordionGroup>

***

## Optie B — OAuth 2.0-serviceapplicatie

Gebruik deze methode als uw beveiligingsbeleid geen langlevende API-tokens toestaat. Hierbij wordt het token vervangen door een Klant-ID en een RSA-sleutelpaar waarvan u zelf eigenaar bent. In het platform is dit de tegel **Okta (OAuth 2.0)**, onder **Instellingen → Integraties → Catalog**.

Om met Okta te authenticeren via Client Credentials hebt u het volgende nodig:

1. **Klant-ID** - Een unieke identificatie voor uw Okta API Services-applicatie.
2. **Private Key (JWK)** - De RSA-privésleutel in JSON Web Key-indeling, waarvan de publieke sleutel is geregistreerd in uw Okta-applicatie.
3. **Okta Domain** - Alleen het subdomein van uw Okta-tenant (bijv. `dev-12345678`), niet de volledige hostnaam.
4. **Scopes** - Een door spaties gescheiden lijst met scopes van de Okta Management API (bijv. `okta.users.read okta.logs.read`).

Deze handleiding begeleidt u bij het aanmaken van een API Services-applicatie in Okta met `private_key_jwt`-authenticatie.

### Vereisten:

* U moet een Okta-account hebben. Meld u aan voor een gratis ontwikkelaarsaccount via [developer.okta.com](https://developer.okta.com/signup/).

#### Stap 1: Uw Okta API Services-applicatie aanmaken

1. Log in bij uw [Okta Admin Console](https://login.okta.com/).
2. Navigeer in de linkerzijbalk naar **Applications** > **Applications**.
3. Klik op **Create App Integration**.
4. Selecteer **API Services** als aanmeldmethode en klik op **Volgende**.

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

5. Geef uw applicatie een naam en klik op **Opslaan**.
6. Zoek op het tabblad **General** van de applicatie uw **Klant-ID** — die hebt u nodig in de laatste stap.
7. Stel Client authentication in op **Public key / Private key**. `okta.*`-scopes worden alleen met deze authenticatiemethode ondersteund.

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

8. Schakel **Proof of possession (DPoP)** uit — dit wordt niet ondersteund.

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

<Note>
  De applicatie moet worden aangemaakt als **API Services**.
</Note>

#### Stap 2: Uw RSA-sleutelpaar genereren en registreren

##### De sleutelgenerator van Okta gebruiken

Okta kan het RSA-sleutelpaar rechtstreeks in de Admin Console voor u genereren:

1. Open in de Admin Console uw API Services-applicatie.
2. Ga naar het tabblad **General** en scrol naar de sectie **PUBLIC KEYS**.
3. Klik op **Add Key** en selecteer vervolgens **Generate new key**.
4. Klik op **Opslaan** — Okta genereert het sleutelpaar en toont de **Private Key (JWK)** één keer.
5. Kopieer en bewaar de JSON van de privésleutel onmiddellijk — deze wordt niet opnieuw getoond.

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

6. De publieke sleutel wordt automatisch geregistreerd bij uw applicatie.

<Note>
  Kopieer de private JWK voordat u het dialoogvenster sluit. Plak deze in de laatste stap in het veld **Private Key** in het Living Security Platform.
</Note>

##### Uw eigen sleutel aanmaken

Okta gebruikt `private_key_jwt` voor API Services-apps. U genereert een RSA-sleutelpaar, registreert de **publieke** JWK bij Okta en levert de **private** JWK aan het Living Security Platform.

**Genereer een private JWK** met het volgende Node.js-script (vereist 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));
```

**Registreer de publieke JWK in Okta:**

1. Open in de Admin Console uw API Services-applicatie.
2. Ga naar het tabblad **General** en scrol naar de sectie **PUBLIC KEYS**.
3. Klik op **Add Key**, plak de **JSON van de publieke JWK** uit de uitvoer van het bovenstaande script en klik op **Opslaan**.

<Note>
  De private JWK is wat u in het Living Security Platform plakt. Deze bevat al het sleutelmateriaal (`d`, `p`, `q`, `dp`, `dq`, `qi`) en de `kid`. Houd deze geheim.
</Note>

#### Stap 3: Uw Okta Domain vinden

Voer alleen het subdomein van uw Okta-tenant in — het deel vóór `.okta.com`.

* In de Admin Console toont de adresbalk van uw browser een URL zoals `https://dev-12345678-admin.okta.com`.
* Uw **Okta Domain** is alleen het subdomein (bijv. `dev-12345678`), niet `dev-12345678.okta.com`.
* U kunt ook in de Admin Console naar **Settings** > **Account** gaan om uw Okta-domein te vinden en vervolgens het subdomeingedeelte gebruiken.

#### Stap 4: API-scopes aan uw applicatie toekennen

Okta vereist minimaal één scope in elke tokenaanvraag. Voordat uw applicatie specifieke scopes kan aanvragen, moeten die worden toegekend:

1. Navigeer in de Admin Console naar **Applications** > **Applications** en open uw applicatie.
2. Klik op het tabblad **Okta API Scopes**.
3. Ken de scopes toe die uw integratie nodig heeft: `okta.users.read` en `okta.logs.read`.

Een volledige lijst met beschikbare scopes vindt u in de [Okta Management API-referentie](https://developer.okta.com/docs/api/oauth2/#okta-admin-management).

#### Stap 5: Een beheerdersrol aan uw applicatie toewijzen

Alleen scopes toekennen is niet voldoende — endpoints van de Okta Management API (bijv. `/api/v1/users`) retourneren stilzwijgend een leeg `200 []`-antwoord als uw applicatie geen beheerdersrol heeft. U moet minimaal **Read-Only Administrator** toewijzen:

1. Navigeer in de Admin Console naar **Security** > **Administrators** (of ga naar **Applications** > **Applications** > uw app > **Admin roles**).
2. Klik op **Add administrator assignment** en selecteer uw API Services-applicatie.

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

3. Wijs de rol **Read-Only Administrator** toe (of een hogere rol, afhankelijk van de scopes die u nodig hebt).
4. Klik op **Opslaan**.

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

<Note>
  Zonder beheerdersrol slagen API-aanroepen met `200 OK`, maar leveren ze lege resultaten op en is er geen `403`-fout die op het probleem wijst.
</Note>

#### Stap 6: Referenties invoeren in het Living Security Platform

Zodra u uw **Klant-ID**, **Private Key (JWK)**, **Okta Domain** en **Scopes** hebt:

1. Open het formulier waarin u zich bij Okta moet authenticeren (Client Credentials).
2. Voer uw **Klant-ID** in.
3. Plak uw **Private Key (JWK)** — het volledige JSON-object uit het bovenstaande script (op één regel of opgemaakt).
4. Voer uw **Okta Domain** in als alleen het tenant-subdomein (bijv. `dev-12345678`).
5. Voer de **Scopes** in als een door spaties gescheiden lijst (bijv. `okta.users.read okta.logs.read`).
6. Verstuur het formulier, waarna u succesvol geauthenticeerd zou moeten zijn.

U bent nu verbonden met Okta (Client Credentials).

***

<Note>Delen van deze documentatie zijn overgenomen en aangepast van [Nango](https://nango.dev/docs/), gebruikt onder de [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.