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.
Vorbereitung
- Erstellen Sie einen Service-Account, der nur die Berechtigungen besitzt, die die Integration benötigt.
- Verwenden Sie eine Verwaltungs-Credential mit
service_account:manageund 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 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:
Python
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.
ididentifiziert die Plattformressource. Speichern Sie ihn für Abruf und Widerruf.client_ididentifiziert den Client beim Token-Austausch. Er ist nicht die ID der Plattformressource. Er kannnullsein, solange die Erstellung aussteht.client_secretwird nur an die Anfrage zurückgegeben, die die Erstellung abschließt. Jede wiederholte Erstellungsanfrage liefertnull, 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 keinenIdempotent-Replayed-Header zurück.
Informationen zu Anfrage-IDs und zur Wiederherstellung finden Sie unter Fehler.
Senden Sie niemals ein Client-Secret oder ein Zugriffstoken mit einer Support-Anfrage.
Prüfen und widerrufen
Verwenden Sie Ihre Verwaltungs-Credential und die Plattformressourceid:
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.

