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

# Einrichtung der Okta-Integration

> Verbinden Sie Okta mit Living Security für Benutzerlebenszyklus, Authentifizierung, MFA und administrative Aktivitäten.

export const PublicIntegrationNextSteps = () => <>
    <hr />
    <h2>Weiterführende Ressourcen</h2>
    <ul>
      <li>
        <a href="/de/signals/data-sources">Erfahren Sie, wie Daten aus Integrationen zu Signalen für das Human Risk Management werden</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/integrations">Living Security Integrationen entdecken</a>
      </li>
      <li>
        <a href="https://app.livingsecurity.ai/">Living Security Platform öffnen</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/request-demo/">Living Security Demo anfordern</a>
      </li>
    </ul>
  </>;

export const EgressIpSafelist = ({system}) => <Note>
    <strong>Fügen Sie alle vier Egress-IP-Adressen der Living Security Synchronisierung</strong> in {system} zur Allowlist hinzu.{' '}
    Geben Sie jede Adresse als einzelnen Host mit <code>/32</code> an, wenn {system} die CIDR-Notation erwartet:
    <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 />
    Der Datenverkehr kann von jeder der vier Adressen ausgehen. Wenn nur einige davon in die Allowlist aufgenommen werden, kommt es daher zu sporadischen Synchronisierungsfehlern. Diese vier Adressen sind in jeder Living Security Region identisch. Die vollständige Liste, die Änderungsrichtlinie und Hinweise zur Fehlerbehebung finden Sie unter{' '}
    <a href="/de/integrations/managing/egress-ip-addresses">
      Egress-IP-Adressen für Integrationen konfigurieren
    </a>.
  </Note>;

export const ConnectInPlatform = ({tile, children}) => <Step title="Zugangsdaten in der Living Security Platform eingeben">
    <p>
      Wird von der Person durchgeführt, die über Living Security-Zugriff verfügt – dem Programmverantwortlichen oder dem Systemadministrator, sofern dieser eingeladen wurde (delegierte Einrichtung).
    </p>
    <ol>
      <li>
        Gehen Sie zu <strong>Einstellungen → Integrationen → Catalog</strong>, suchen Sie die Kachel{' '}
        <strong>{tile}</strong> und klicken Sie auf <strong>Verbinden</strong>.
      </li>
      <li>
        Füllen Sie die folgenden Felder aus und klicken Sie anschließend auf <strong>Verbinden</strong>.
      </li>
    </ol>
    {children}
  </Step>;

## Überblick

Okta kann normalisierte Daten zu Benutzerlebenszyklus, Authentifizierung, MFA und administrativen Aktivitäten beisteuern. Geprüfte Beispiele sind:

* `account.locked` — Konto gesperrt
* `mfa.factor.activated` — aktiviert zusätzliche MFA-Faktoren
* `auth.login.failed` — Anmeldung schlägt fehl

Beide Verbindungsmethoden lesen dieselben zwei Datenströme — das Benutzerverzeichnis (`/api/v1/users`) und das Systemprotokoll (`/api/v1/logs`). Siehe [wie Integrationsdaten zu Signalen werden](/de/signals/data-sources).

## Verbindungsmethode auswählen

| | **Okta (SSWS)** | **Okta (OAuth 2.0)** |
| - | - | - |
| Zugangsdaten | Ein API-Token, das Sie in der Admin Console erstellen | Eine Client-ID und ein privater JWK, die Sie generieren und registrieren |
| Einrichtung | Drei Schritte, kein Schlüsselmaterial zu generieren | Neun Schritte, einschließlich eines RSA-Schlüsselpaars |
| Erforderliche Administratorrolle | Read-only Administrator, dem Inhaber des Tokens zugewiesen | Read-only Administrator, der Anwendung zugewiesen |
| Token-Lebensdauer | Wird nach 30 Tagen ohne Nutzung deaktiviert | Kein Ablauf; die Rotation des Schlüsselpaars liegt bei Ihnen |
| Einsatz empfohlen, wenn | Dies ist der empfohlene Weg für die meisten Organisationen | Ihre Sicherheitsrichtlinie langlebige API-Tokens verbietet |

Beide Methoden benötigen denselben Zugriff; die Wahl betrifft also den Umgang mit Zugangsdaten und nicht, was die Plattform lesen kann.

***

## Option A — API-Token (SSWS)

*Empfohlen.*

### Was Living Security benötigt

| Zugangsdaten | Beschreibung |
| - | - |
| **API-Schlüssel** | Ein Okta-API-Token. Der Verbindungsdialog bezeichnet dieses Feld als **API-Schlüssel** |
| **Tenant-Subdomain** | Der `<tenant>` in `<tenant>.okta.com` — nur die Subdomain, nicht die vollständige URL |

### Voraussetzungen

* Sie müssen in Okta **Super Administrator** sein, um einen Servicekonto-Benutzer zu erstellen, Administratorrollen zuzuweisen und API-Tokens zu erstellen.

<Steps>
  <Step title="Benutzer als Inhaber des Tokens erstellen">
    Ein Okta-API-Token hat die Berechtigungen des Benutzers, der es erstellt hat, und funktioniert nicht mehr, wenn dieser Benutzer deaktiviert wird. Erstellen Sie ein dediziertes Servicekonto, anstatt ein persönliches Administratorkonto zu verwenden, damit die Verbindung Personalwechsel übersteht.

    1. Gehen Sie in der Admin Console zu **Directory** → **People**.
    2. Klicken Sie auf **Add person** und erstellen Sie einen Benutzer wie `svc-livingsecurity@yourcompany.com`.
    3. Aktivieren Sie das Konto.
  </Step>

  <Step title="Rolle „Read-only Administrator“ zuweisen">
    Die Plattform liest ausschließlich. Mehr als Lesezugriff zu gewähren, würde dem Token Berechtigungen geben, die es nie nutzt.

    1. Gehen Sie zu **Security** → **Administrators**.
    2. Klicken Sie auf **Add administrator** und wählen Sie den Benutzer aus dem vorherigen Schritt aus.
    3. Weisen Sie die Rolle **Read-only Administrator** zu.
    4. Speichern Sie.

    <Note>
      Ohne Administratorrolle sind Aufrufe der Okta Management API mit `200 OK` erfolgreich und liefern eine leere Liste zurück. Es gibt keinen `403`, der Sie auf die fehlende Rolle hinweist — die Datenströme bleiben einfach leer.
    </Note>
  </Step>

  <Step title="API-Token erstellen">
    1. Melden Sie sich **als Servicekonto-Benutzer** aus Schritt 1 bei der Admin Console an. Das Token übernimmt die Berechtigungen des Kontos, das es erstellt.
    2. Gehen Sie zu **Security** → **API** und öffnen Sie die Registerkarte **Tokens**.
    3. Klicken Sie auf **Create token**, vergeben Sie einen Namen wie `Living Security Platform` und klicken Sie auf **Create token**.
    4. Kopieren Sie den Token-Wert jetzt — Okta zeigt ihn nur einmal an und nie wieder.

    <Warning>
      Okta deaktiviert ein API-Token nach **30 Tagen ohne Nutzung**. Die Synchronisierungen dieser Integration laufen mindestens einmal täglich, sodass eine aktive Verbindung ihr eigenes Token am Leben hält. Eine Verbindung, die einen Monat lang pausiert war, benötigt ein neues Token.
    </Warning>

    <EgressIpSafelist system="Okta" />

    <Note>
      Die obige Adressliste ist nur relevant, wenn Ihre Okta-Organisation den API-Zugriff über **Netzwerkzonen** einschränkt. Bei den meisten Organisationen ist dies nicht der Fall.
    </Note>
  </Step>

  <Step title="Tenant-Subdomain ermitteln">
    Ihre Admin-Console-URL sieht aus wie `https://acme-admin.okta.com`. Die Tenant-Subdomain ist `acme` — ohne das Suffix `-admin`, ohne `.okta.com` und ohne `https://`.
  </Step>

  <ConnectInPlatform tile="Okta (SSWS)">
    | Feld | Wert |
    | - | - |
    | **API-Schlüssel** | Das API-Token aus Schritt 3 |
    | **Tenant-Subdomain** | Die Subdomain aus Schritt 4 (z. B. `acme`) |
  </ConnectInPlatform>
</Steps>

Sie sind nun mit Okta (SSWS) verbunden.

### Fehlerbehebung

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    Das Token ist ungültig, wurde widerrufen oder nach 30 Tagen Inaktivität deaktiviert. Erstellen Sie als Servicekonto-Benutzer ein neues Token und geben Sie es erneut in der Verbindung ein.
  </Accordion>

  <Accordion title="Verbunden, aber alle Datenströme sind leer">
    Der Inhaber des Tokens hat keine Administratorrolle. Weisen Sie dem Servicekonto **Read-only Administrator** zu (Schritt 2) — die API gibt `200 OK` mit einer leeren Liste zurück, statt einen Fehler zu melden, wenn die Rolle fehlt.
  </Accordion>

  <Accordion title="Synchronisierungen schlagen nach einem Personalwechsel fehl">
    Das Token funktioniert nicht mehr, wenn der Benutzer, der es erstellt hat, deaktiviert wird. Deshalb sollte das Token einem Servicekonto und nicht einer Person gehören.
  </Accordion>
</AccordionGroup>

***

## Option B — OAuth-2.0-Dienstanwendung

Verwenden Sie diese Methode, wenn Ihre Sicherheitsrichtlinie langlebige API-Tokens nicht zulässt. Sie ersetzt das Token durch eine Client-ID und ein RSA-Schlüsselpaar, das Ihnen gehört. In der Plattform ist dies die Kachel **Okta (OAuth 2.0)** unter **Einstellungen → Integrationen → Catalog**.

Für die Authentifizierung bei Okta mit Client Credentials benötigen Sie Folgendes:

1. **Client-ID** – Eine eindeutige Kennung für Ihre Okta-API-Services-Anwendung.
2. **Privater Schlüssel (JWK)** – Der private RSA-Schlüssel im JSON-Web-Key-Format, dessen öffentlicher Schlüssel in Ihrer Okta-Anwendung registriert ist.
3. **Okta-Domain** – Nur die Subdomain Ihres Okta-Tenants (z. B. `dev-12345678`), nicht der vollständige Hostname.
4. **Scopes** – Eine durch Leerzeichen getrennte Liste von Okta-Management-API-Scopes (z. B. `okta.users.read okta.logs.read`).

Diese Anleitung führt Sie durch die Erstellung einer API-Services-Anwendung in Okta mit `private_key_jwt`-Authentifizierung.

### Voraussetzungen:

* Sie benötigen ein Okta-Konto. Registrieren Sie sich unter [developer.okta.com](https://developer.okta.com/signup/) für ein kostenloses Entwicklerkonto.

#### Schritt 1: Okta-API-Services-Anwendung erstellen

1. Melden Sie sich bei Ihrer [Okta Admin Console](https://login.okta.com/) an.
2. Navigieren Sie in der linken Seitenleiste zu **Applications** > **Applications**.
3. Klicken Sie auf **Create App Integration**.
4. Wählen Sie **API Services** als Anmeldemethode aus und klicken Sie auf **Weiter**.

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

5. Geben Sie Ihrer Anwendung einen Namen und klicken Sie auf **Speichern**.
6. Auf der Registerkarte **General** der Anwendung finden Sie Ihre **Client-ID** — Sie benötigen sie im letzten Schritt.
7. Setzen Sie Client authentication auf **Public key / Private key**. `okta.*`-Scopes werden nur mit dieser Authentifizierungsmethode unterstützt.

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

8. Deaktivieren Sie **Proof of possession (DPoP)** — es wird nicht unterstützt.

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

<Note>
  Die Anwendung muss als **API Services** erstellt werden.
</Note>

#### Schritt 2: RSA-Schlüsselpaar generieren und registrieren

##### Okta-Schlüsselgenerator verwenden

Okta kann das RSA-Schlüsselpaar direkt in der Admin Console für Sie generieren:

1. Öffnen Sie in der Admin Console Ihre API-Services-Anwendung.
2. Gehen Sie zur Registerkarte **General** und scrollen Sie zum Abschnitt **PUBLIC KEYS**.
3. Klicken Sie auf **Add Key** und wählen Sie dann **Generate new key**.
4. Klicken Sie auf **Speichern** — Okta generiert das Schlüsselpaar und zeigt den **privaten Schlüssel (JWK)** einmalig an.
5. Kopieren Sie den JSON-Code des privaten Schlüssels sofort und speichern Sie ihn — er wird nicht erneut angezeigt.

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

6. Der öffentliche Schlüssel wird automatisch bei Ihrer Anwendung registriert.

<Note>
  Kopieren Sie den privaten JWK, bevor Sie den Dialog schließen. Fügen Sie ihn im letzten Schritt in das Feld **Private Key** in der Living Security Platform ein.
</Note>

##### Eigenen Schlüssel erstellen

Okta verwendet `private_key_jwt` für API-Services-Anwendungen. Sie generieren ein RSA-Schlüsselpaar, registrieren den **öffentlichen** JWK bei Okta und übergeben den **privaten** JWK an die Living Security Platform.

**Generieren Sie einen privaten JWK** mit dem folgenden Node.js-Skript (erfordert 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));
```

**Öffentlichen JWK in Okta registrieren:**

1. Öffnen Sie in der Admin Console Ihre API-Services-Anwendung.
2. Gehen Sie zur Registerkarte **General** und scrollen Sie zum Abschnitt **PUBLIC KEYS**.
3. Klicken Sie auf **Add Key**, fügen Sie die vom obigen Skript ausgegebene **öffentliche JWK-JSON** ein und klicken Sie auf **Speichern**.

<Note>
  Der private JWK ist derjenige, den Sie in die Living Security Platform einfügen. Er enthält das gesamte Schlüsselmaterial (`d`, `p`, `q`, `dp`, `dq`, `qi`) und die `kid`. Halten Sie ihn geheim.
</Note>

#### Schritt 3: Okta-Domain ermitteln

Geben Sie nur die Subdomain Ihres Okta-Tenants ein — den Teil vor `.okta.com`.

* In der Admin Console zeigt die Adressleiste Ihres Browsers eine URL wie `https://dev-12345678-admin.okta.com`.
* Ihre **Okta-Domain** ist nur die Subdomain (z. B. `dev-12345678`), nicht `dev-12345678.okta.com`.
* Alternativ gehen Sie in der Admin Console zu **Settings** > **Account**, um Ihre Okta-Domain zu finden, und verwenden dann den Subdomain-Teil.

#### Schritt 4: API-Scopes für Ihre Anwendung gewähren

Okta erfordert in jeder Token-Anfrage mindestens einen Scope. Bevor Ihre Anwendung bestimmte Scopes anfordern kann, müssen diese gewährt werden:

1. Navigieren Sie in der Admin Console zu **Applications** > **Applications** und öffnen Sie Ihre Anwendung.
2. Klicken Sie auf die Registerkarte **Okta API Scopes**.
3. Gewähren Sie die Scopes, die Ihre Integration benötigt: `okta.users.read` und `okta.logs.read`.

Eine vollständige Liste der verfügbaren Scopes finden Sie in der [Okta-Management-API-Referenz](https://developer.okta.com/docs/api/oauth2/#okta-admin-management).

#### Schritt 5: Administratorrolle Ihrer Anwendung zuweisen

Das Gewähren von Scopes allein genügt nicht — Endpunkte der Okta Management API (z. B. `/api/v1/users`) geben stillschweigend eine leere `200 []`-Antwort zurück, wenn Ihre Anwendung keine Administratorrolle hat. Sie müssen mindestens **Read-Only Administrator** zuweisen:

1. Navigieren Sie in der Admin Console zu **Security** > **Administrators** (oder gehen Sie zu **Applications** > **Applications** > Ihre Anwendung > **Admin roles**).
2. Klicken Sie auf **Add administrator assignment** und wählen Sie Ihre API-Services-Anwendung aus.

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

3. Weisen Sie die Rolle **Read-Only Administrator** zu (oder eine höhere, abhängig von den benötigten Scopes).
4. Klicken Sie auf **Speichern**.

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

<Note>
  Ohne Administratorrolle sind API-Aufrufe mit `200 OK` erfolgreich, liefern aber leere Ergebnisse, und es gibt keinen `403`-Fehler, der auf das Problem hinweist.
</Note>

#### Schritt 6: Zugangsdaten in der Living Security Platform eingeben

Sobald Sie Ihre **Client-ID**, Ihren **privaten Schlüssel (JWK)**, Ihre **Okta-Domain** und Ihre **Scopes** haben:

1. Öffnen Sie das Formular, in dem Sie sich bei Okta (Client Credentials) authentifizieren müssen.
2. Geben Sie Ihre **Client-ID** ein.
3. Fügen Sie Ihren **privaten Schlüssel (JWK)** ein — das vollständige JSON-Objekt aus dem obigen Skript (einzeilig oder formatiert).
4. Geben Sie Ihre **Okta-Domain** nur als Tenant-Subdomain ein (z. B. `dev-12345678`).
5. Geben Sie die **Scopes** als durch Leerzeichen getrennte Liste ein (z. B. `okta.users.read okta.logs.read`).
6. Senden Sie das Formular ab; die Authentifizierung sollte nun erfolgreich sein.

Sie sind nun mit Okta (Client Credentials) verbunden.

***

<Note>Teile dieser Dokumentation sind von [Nango](https://nango.dev/docs/) übernommen und angepasst und werden unter der [Elastic License 2.0](https://github.com/NangoHQ/nango?tab=License-1-ov-file#readme) verwendet.</Note>

<PublicIntegrationNextSteps />


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