Skip to main content
Sie benötigen OAuth nicht, um die Public API zu verwenden. Beginnen Sie für eine private, serverseitige Integration mit einem API-Schlüssel mit begrenztem Geltungsbereich und folgen Sie dem Schnellstart. Wählen Sie OAuth-Client-Credentials, wenn Ihre Sicherheitsrichtlinie kurzlebige Zugriffstoken erfordert oder Ihre Integrationsplattform diesen Flow bereits unterstützt. Beide Optionen verwenden ein Servicekonto. Ein Servicekonto ist die Identität der Integration, keine dritte Authentifizierungsmethode.

​
Wie die einzelnen Komponenten zusammenwirken

Erstellen Sie pro Integration ein Servicekonto. Wählen Sie für dieses Konto einen API-Schlüssel oder einen OAuth-Client; Sie benötigen nicht beide Methoden für jede API-Anfrage. Keines der beiden Anmeldedaten kann die aktuellen Berechtigungen des Kontos überschreiten. Der Schnellstart verwendet die Basic-Authentifizierung. Für API-Schlüssel wird auch ein Bearer-Header unterstützt; die Verwendung dieses Headers bedeutet nicht, dass Sie einen OAuth-Client benötigen.

​
API-Schlüssel für eine unkomplizierte Integration wählen

Verwenden Sie einen API-Schlüssel für Ihre eigenen geplanten Jobs, Reporting-Skripte, Datenpipelines oder andere Backend-Services, wenn ein in Ihrem Secret-Manager gespeichertes Geheimnis Ihren Sicherheitsanforderungen entspricht.
  • Senden Sie authentifizierte Anfragen direkt; ein Token-Austausch ist nicht erforderlich.
  • Wählen Sie nur die Berechtigungen aus, die die Workload benötigt, und legen Sie ein Ablaufdatum fest.
  • Rotieren Sie den Schlüssel mithilfe seines Überlappungszeitraums oder widerrufen Sie ihn sofort, falls er offengelegt wurde.
Eine Integration mit API-Schlüssel benötigt keinen OAuth-Client. Beginnen Sie mit dem Schnellstart und lesen Sie anschließend API-Schlüssel zu Erstellung und Rotation.

​
OAuth für kurzlebige Zugriffstoken wählen

Verwenden Sie OAuth-Client-Credentials für einen vertraulichen Backend-Service, wenn Ihre Organisation ablaufende Zugriffstoken verlangt oder ein Integrationstool den client_credentials-Grant erwartet.
  1. Erstellen Sie einen OAuth-Client mit begrenztem Geltungsbereich für das Servicekonto.
  2. Authentifizieren Sie den Client bei Ihrem regionalen Token-Endpunkt mit der Client-Authentifizierungsmethode, die Ihnen bei der Einrichtung bereitgestellt wurde.
  3. Senden Sie das erhaltene Zugriffstoken mit Ihren API-Anfragen. Fordern Sie ein neues Token an, bevor das aktuelle Token abläuft.
OAuth erweitert Ihre Integration um das Abrufen von Token und die Behandlung von Ablaufzeiten. Das Client-Geheimnis muss weiterhin sicher gespeichert und rotiert werden; kurzlebige Token heben diese Verantwortung nicht auf. Client-Credentials verwendet keine Refresh-Token: Authentifizieren Sie den Client erneut, um ein neues Zugriffstoken zu erhalten. Der OAuth-Zugriff muss für Ihre Organisation aktiviert sein. Falls er nicht aktiviert ist, verwenden Sie einen API-Schlüssel oder wenden Sie sich mit Ihren Anforderungen an den Living Security Support. Informationen zu Client-Erstellung, einmalig angezeigten Geheimnissen, Widerruf und Wiederherstellung finden Sie unter OAuth-Client-Credentials.

​
Anmeldedaten auf Ihrem Backend aufbewahren

API-Schlüssel von Servicekonten und OAuth-Client-Geheimnisse gehören in einen serverseitigen Speicher für Geheimnisse. Legen Sie sie nicht in Browsercode, mobilen Apps, Versionsverwaltung oder Logs ab. Die Anmeldedaten eines Servicekontos agieren als die Workload; sie melden keine Person an und bieten keinen Flow für die Zustimmung von Kunden. Verwenden Sie bei beiden Methoden den regionalen API-Host für Ihre Organisation. Ein Wechsel der Authentifizierungsmethode ändert weder die Ressourcen-URL, die API-Version noch die Berechtigungen, die ein Vorgang erfordert.