Einrichtung der Okta-Integration

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

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.

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.

Gehen Sie in der Admin Console zu Directory → People.
Klicken Sie auf Add person und erstellen Sie einen Benutzer wie svc-livingsecurity@yourcompany.com.
Aktivieren Sie das Konto.

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.

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

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.

API-Token erstellen

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

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.

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.

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://.

Sie sind nun mit Okta (SSWS) verbunden.

Fehlerbehebung

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.

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.

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.

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:

Client-ID – Eine eindeutige Kennung für Ihre Okta-API-Services-Anwendung.
Privater Schlüssel (JWK) – Der private RSA-Schlüssel im JSON-Web-Key-Format, dessen öffentlicher Schlüssel in Ihrer Okta-Anwendung registriert ist.
Okta-Domain – Nur die Subdomain Ihres Okta-Tenants (z. B. dev-12345678), nicht der vollständige Hostname.
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 für ein kostenloses Entwicklerkonto.

Schritt 1: Okta-API-Services-Anwendung erstellen

Melden Sie sich bei Ihrer Okta Admin Console an.
Navigieren Sie in der linken Seitenleiste zu Applications > Applications.
Klicken Sie auf Create App Integration.
Wählen Sie API Services als Anmeldemethode aus und klicken Sie auf Weiter.

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

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

Die Anwendung muss als API Services erstellt werden.

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:

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

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

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.

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+):

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:

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

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.

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:

Navigieren Sie in der Admin Console zu Applications > Applications und öffnen Sie Ihre Anwendung.
Klicken Sie auf die Registerkarte Okta API Scopes.
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.

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:

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

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

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

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:

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

Sie sind nun mit Okta (Client Credentials) verbunden.

Teile dieser Dokumentation sind von Nango übernommen und angepasst und werden unter der Elastic License 2.0 verwendet.

Integrationen

Integrationseinrichtung

Katalog

Ausgehende Kanäle

Überblick

Verbindungsmethode auswählen