> ## 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. # OAuth-Client-Credentials > Richten Sie einen Service-Account-Client mit eingeschränktem Umfang ein, gehen Sie mit einmalig angezeigten Secrets um und stellen Sie den Zustand bei unklaren Anfragen sicher wieder her. Verwenden Sie OAuth-Client-Credentials, wenn Ihre Backend-Integration kurzlebige Zugriffstoken benötigt oder Ihre Sicherheitsrichtlinie sie vorschreibt. Jeder Client gehört zu genau einem Service-Account und einer Organisation. **OAuth ist optional:** Ein API-Schlüssel mit eingeschränktem Umfang reicht für eine private Server-Integration aus, die einen Schlüssel sicher speichern und rotieren kann. Unter [Authentifizierung](/de/developers/v1/authentication) erfahren Sie, wie Sie zwischen den beiden Methoden wählen und wie Service-Accounts dazu passen. Der OAuth-Zugriff muss für Ihre Organisation aktiviert sein. Im Rahmen Ihrer Einrichtung erhalten Sie den regionalen Token-Endpunkt, den Issuer, die Audience und die Methode zur Client-Authentifizierung. Wenn Sie diese Einstellungen benötigen oder nicht auf die Client-Verwaltung zugreifen können, wenden Sie sich an den Living Security Support. Der Client-Credentials-Grant steht für Ihren Service-Account. Er meldet weder eine Person an noch fordert er einen Kunden auf, eine Anwendung zu autorisieren. Die delegierte Autorisierung über einen Browser ist eine separate OAuth-Funktion und wird von diesen Operationen nicht angeboten. ## Vorbereitung * Erstellen Sie einen [Service-Account](/de/developers/developer-hub/service-accounts), der nur die Berechtigungen besitzt, die die Integration benötigt. * Verwenden Sie eine Verwaltungs-Credential mit `service_account:manage` und jeder Berechtigung, die Sie dem neuen Client erteilen möchten. Der Ziel-Account muss diese Berechtigungen ebenfalls besitzen. Ein Client kann die Befugnisse keines der beiden Accounts erweitern. * Wählen Sie die [Region](/de/developers/v1/regions) der Organisation. API-Credentials und OAuth-Zugriffstoken gehören auf den passenden regionalen API-Host. * Bewahren Sie das Client-Secret und die Token in Ihrem serverseitigen Secret-Speicher auf. Legen Sie sie niemals in Browser-Code, mobilen Anwendungen, Versionsverwaltung oder Anfrageprotokollen ab. ## Client erstellen `POST /v1/oauth_clients` erfordert `service_account_id`, eine nicht leere Liste expliziter `scopes` und einen `Idempotency-Key`. Platzhalterzeichen (Wildcards) werden nicht akzeptiert. Ein Client unterstützt bis zu 100 Scopes mit einer Gesamtlänge von höchstens 4.096 Zeichen. Jeder Service-Account kann höchstens 20 Clients oder ungelöste Erstellungs-/Bereinigungsvorgänge haben. Das Widerrufen verweigert den API-Zugriff sofort. Ein Client oder eine unklare Erstellung beim Provider zählt so lange auf das Limit, bis die Bereinigung auf der Gegenseite bestätigt ist. Eine verworfene Reservierung oder eine Erstellung, die nachweislich fehlgeschlagen ist, bevor die Arbeit beim Provider begann, kann ihren Platz gefahrlos freigeben. Der zugehörige Wiederholungsschlüssel gehört weiterhin zum ursprünglichen Versuch; stellen Sie diesen Beleg wieder her, bevor Sie entscheiden, ob Sie einen Ersatz erstellen. Wählen Sie für diesen Erstellungsversuch einen Wiederholungsschlüssel und speichern Sie ihn dauerhaft, **bevor** Sie die Anfrage senden. Verwenden Sie 1–255 sichtbare ASCII-Zeichen ohne Leerzeichen. Verwenden Sie ihn nach einer verlorenen Antwort erneut mit demselben Account, denselben Scopes, demselben Verwaltungs-Principal, derselben Region und derselben API-Version. Die Rotation der Verwaltungs-Credential unter demselben Service-Account erzeugt keine neue Wiederholungsidentität. Installieren Sie das Python-Paket `requests`. Laden Sie die folgenden Umgebungswerte über Ihre übliche Secret- und Konfigurationsverwaltung: | Variable | Wert | | - | - | | `LIVING_SECURITY_API_KEY` | Verwaltungs-API-Schlüssel | | `LIVING_SECURITY_REGION` | `us` oder `eu` | | `LIVING_SECURITY_SERVICE_ACCOUNT_ID` | ID des Ziel-Service-Accounts | | `LIVING_SECURITY_OAUTH_CREATE_KEY` | Zuvor gespeicherter Wiederholungsschlüssel | ```python Python theme={null} import os import requests HOSTS = { "us": "https://api.us-east-1.livingsecurity.ai/v1", "eu": "https://api.eu-west-1.livingsecurity.ai/v1", } base = HOSTS[os.environ["LIVING_SECURITY_REGION"]] response = requests.post( f"{base}/oauth_clients", auth=("apikey", os.environ["LIVING_SECURITY_API_KEY"]), headers={ "Living-Security-Version": "2026-07-01", "Idempotency-Key": os.environ["LIVING_SECURITY_OAUTH_CREATE_KEY"], }, json={ "service_account_id": os.environ["LIVING_SECURITY_SERVICE_ACCOUNT_ID"], "scopes": ["organization:read"], }, timeout=(5, 30), allow_redirects=False, ) try: if response.status_code != 201: raise RuntimeError( f"Client creation needs review: HTTP {response.status_code}; " f"request_id={response.headers.get('Request-Id', 'unknown')}" ) client = response.json() if client.get("object") != "oauth_client" or not client.get("id"): raise RuntimeError("Unexpected client receipt; preserve the retry key") if client.get("status") != "active" or not client.get("client_secret"): raise RuntimeError( f"Client {client['id']} needs recovery; no usable secret was returned" ) # Persist client['id'], client['client_id'], and client['client_secret'] # directly in your secret manager before using the client. Do not print them. finally: response.close() ``` Das Beispiel sendet eine Anfrage und hält das Ergebnis im Arbeitsspeicher. Fügen Sie an der markierten Stelle den Schreibvorgang Ihres Secret-Managers hinzu, bevor Sie es in der Produktion ausführen. Nach einem unklaren Ergebnis verlangt es bewusst eine Entscheidung, statt stillschweigend einen weiteren Client zu erstellen. Auch Netzwerkausnahmen erfordern die unten beschriebenen Schritte zur Wiederherstellung. Antworten auf Erstellung und Beleg verwenden `201` und enthalten eine `oauth_client`-Ressource mit `id`, `service_account_id`, `client_id`, `scopes`, `status`, `created_at` und `client_secret`. Antworten sind mit `Cache-Control: no-store` gekennzeichnet. * **`id`** identifiziert die Plattformressource. Speichern Sie ihn für Abruf und Widerruf. * **`client_id`** identifiziert den Client beim Token-Austausch. Er ist nicht die ID der Plattformressource. Er kann `null` sein, solange die Erstellung aussteht. * **`client_secret`** wird nur an die Anfrage zurückgegeben, die die Erstellung abschließt. Jede wiederholte Erstellungsanfrage liefert `null`, auch eine Wiederholung nach einer verlorenen Erfolgsantwort. Beim Abruf wird nie ein Secret zurückgegeben. ## Verlorene oder unterbrochene Antwort wiederherstellen Wiederholen Sie dieselbe Erstellungsanfrage mit dem gespeicherten Wiederholungsschlüssel, um einen Ressourcenbeleg wiederherzustellen. Der Beleg gibt den aktuellen Zustand wieder; ein widerrufener Client bleibt also widerrufen. Dieser Vorgang verwendet nicht den allgemeinen Vertrag zur Wiedergabe zwischengespeicherter Antworten über 24 Stunden und gibt keinen `Idempotent-Replayed`-Header zurück. | Ergebnis | Nächste Maßnahme | | - | - | | `active`, Secret vorhanden | Speichern Sie das Secret sicher und setzen Sie das Onboarding fort. | | `active`, Secret nicht vorhanden | Das Secret kann nicht wiederhergestellt werden. Widerrufen Sie diesen Client, bestätigen Sie den Widerruf und erstellen Sie dann mit einem neuen Wiederholungsschlüssel einen Ersatz. | | `pending` | Die Erstellung ist unbestätigt. Behalten Sie denselben Wiederholungsschlüssel bei. Rufen Sie die Ressource ab, um den Zustand zu prüfen; erstellen Sie keine Duplikate, um die Unsicherheit zu umgehen. | | `revoked`, `disabled` oder `expired` | Verwenden Sie diesen Client nicht. Bestätigen Sie die vorgesehene Account-Konfiguration, bevor Sie einen Ersatz bereitstellen. | | `409 idempotency_key_reuse` | Die Anfrage wurde unter einem bestehenden Schlüssel geändert. Stellen Sie den ursprünglichen Vorgang wieder her, bevor Sie entscheiden, ob eine separate Erstellung nötig ist. | | `409 invalid_request` | Prüfen Sie Status und Berechtigungen des Ziel-Accounts. Wenn dessen Client-Limit erreicht wurde, schließen Sie die Bereinigung ab, bevor Sie es erneut versuchen; ein anderer Wiederholungsschlüssel schafft keine zusätzliche Kapazität. | | `429` | Beachten Sie `Retry-After`; behalten Sie denselben Schlüssel und dieselbe Anfrage bei. | | `500`, `503` oder ein Netzwerk-Timeout | Das Ergebnis ist möglicherweise unbekannt. Bewahren Sie Schlüssel und Eingaben auf; stellen Sie den Beleg wieder her, bevor Sie einen weiteren Client erstellen. | | `401` oder `403` | Klären Sie den Zugriff bezüglich Credential, Berechtigung oder Entitlement, bevor Sie es erneut versuchen. | | `404` | Prüfen Sie die OAuth-Aktivierung, den regionalen Host und die Ressourcenzugehörigkeit. | Informationen zu Anfrage-IDs und zur Wiederherstellung finden Sie unter [Fehler](/de/developers/v1/errors/overview). Senden Sie niemals ein Client-Secret oder ein Zugriffstoken mit einer Support-Anfrage. ## Prüfen und widerrufen Verwenden Sie Ihre Verwaltungs-Credential und die Plattformressource `id`: | Operation | Anfrage | Erfolg | | - | - | - | | Aktuellen Zustand prüfen | `GET /v1/oauth_clients/{id}` | `200`, Client-Ressource ohne Secret | | Zugriff widerrufen | `DELETE /v1/oauth_clients/{id}` | `200`, widerrufene Client-Ressource ohne Secret | Der Widerruf blockiert nachfolgende API-Anfragen des Clients, einschließlich Anfragen mit bereits ausgestellten Token. Von der API bereits angenommene Arbeit wird dadurch nicht abgebrochen. Die Bereinigung der Credentials auf der Gegenseite kann später abgeschlossen werden. Ein wiederholter Widerruf ist unbedenklich und erfordert keinen Wiederholungsschlüssel. Verwenden Sie weiterhin die Verwaltungs-Credential, wenn der zu widerrufende Client selbst ein API-Aufrufer ist. ## Rotieren ohne Zugriffsverlust Erstellen Sie einen zweiten Client mit der erforderlichen Scope-Obergrenze. Speichern Sie sein Secret, beziehen Sie über Ihren regionalen Token-Endpunkt ein Token und prüfen Sie, ob die Integration damit funktioniert. Stellen Sie die Integration auf den Ersatz um und widerrufen Sie dann die alte Ressource. Behalten Sie eine unabhängige Verwaltungs-Credential, damit Sie sich von einem fehlerhaften Rollout erholen können. Zugriffstoken können nicht mehr gewähren als die Scopes des Clients und die aktuellen Berechtigungen des Service-Accounts. Das Entfernen von Account-Berechtigungen oder das Widerrufen eines Clients hat Vorrang vor der verbleibenden Lebensdauer eines Tokens. Betrachten Sie ein zwischengespeichertes Token nicht als Nachweis dafür, dass die Autorisierung noch gültig ist. Beziehen Sie vor Ablauf ein neues Zugriffstoken, indem Sie den Client erneut authentifizieren; dieser Grant verwendet keine Refresh-Token. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.