Zum Inhalt springen

Verwandeln Sie Ihre Kontakte in Urlaubsgeld mit unserem neuen Kundenempfehlungsprogramm! Erfahren Sie mehr

Diese Dokumentation gilt für Version 4 und höher von App Builder, dem neuen Namen für Vinyl. Hier gelangen Sie zur Vinyl-Dokumentation.

API Schlüsselsicherheitsanbieter im Jitterbit App Builder

Der API -Schlüssel-Sicherheitsanbieter ermöglicht Administratoren die Sicherung von App Builder REST APIs mithilfe von API -Schlüsseln. Ein API -Schlüssel ist ein von App Builder generierter Code. Der Verbraucher übergibt den API Schlüssel bei REST API -Anfragen an App Builder. Da jeder API Schlüssel einem einzelnen Benutzer zugeordnet ist, dient dies sowohl der Authentifizierung als auch der Autorisierung.

API -Schlüssel vs. Benutzername und Passwörter

Ein API Schlüssel ähnelt einem Benutzernamen und einem Passwort, da er ein zwischen Client und Server geteiltes Geheimnis darstellt. API -Schlüssel weisen einige Schwächen mit Benutzernamen- und Passwort-Authentifizierungsschemata wie der HTTP-Basisauthentifizierung auf:

  • API -Schlüssel können durchsickern.
  • Die Verteilung von API Schlüsseln kann schwierig zu verwalten sein.

Allerdings haben API -Schlüssel gegenüber Benutzernamen und Passwörtern Vorteile:

  • API -Schlüssel haben eine größere Entropie als Benutzername-/Passwortkombinationen.
  • API -Schlüssel können eine Kennwortzurücksetzung überstehen.
  • API -Schlüssel können einfach widerrufen werden.
  • API -Schlüssel können rotiert werden.
  • API -Schlüssel sind schneller. Passwörter müssen gehasht werden, was absichtlich langsam ist.

API -Schlüssel verwendet

Trotz der Schwächen von API -Schlüsseln können sie für bestimmte Szenarien dennoch geeignet sein, darunter:

  • Service-Level-Konten
  • Kommunikation von Anwendung zu Anwendung Server-zu-Server-Kommunikation
  • Nur-Lese-Zugriff
  • Nicht vertrauliche Informationen

API Schlüsselmaterial

Die API -Schlüssel des App Builders bestehen aus einer 128-Bit-kryptografisch zufälligen Zahl. Die Schlüssel sind base64url-kodiert.

Nachfolgend sehen Sie ein Beispiel für einen API -Schlüssel:

DLOo9sPS5slJEMHpXBFt3g

Konfiguration

Parameter

Der API Schlüssel-Sicherheitsanbieter definiert die folgenden Parameter:

Parameter Standardwert Beschreibung
AllowApiKeyInQueryString False Gibt an, ob der Sicherheitsanbieter API Schlüssel akzeptieren soll, die in der Abfrage übergeben werden. Standardmäßig erlaubt der Sicherheitsanbieter nur die Übergabe von API Schlüsseln in den HTTP-Anforderungsheadern. Weitere Informationen finden Sie unten.
AllowUnsafeHttpConnections False Gibt an, ob der Sicherheitsanbieter API Schlüssel akzeptieren soll, die über eine unsichere HTTP-Anfrage übermittelt wurden. Standardmäßig erlaubt der Sicherheitsanbieter nur die Übermittlung von API Schlüsseln über eine sichere HTTPS-Verbindung. Weitere Informationen finden Sie unten.

HTTP- Header vs. Abfrage

Normalerweise übergibt der Client den API -Schlüssel über einen benutzerdefinierten Header. Der Header muss den Namen X- API-Key tragen. Dies minimiert das Risiko einer Offenlegung. Im Gegensatz zu Abfrage werden HTTP-Header beispielsweise selten auf der Festplatte protokolliert.

Das folgende Beispiel zeigt, wie der API Schlüssel als HTTP- Header übergeben wird:

GET /App Builder/rest/v1/sales/customers HTTP/1.1
Host: example.com:443
Accept: application/json
X-API-Key: DLOo9sPS5slJEMHpXBFt3g

Einige Clients haben möglicherweise keinen Zugriff auf die HTTP-Anforderungsheader. In diesem Fall können Sicherheitsadministratoren die Option AllowApiKeyInQueryString aktivieren, sofern keine andere Problemumgehung verfügbar ist. Dadurch wird App Builder gezwungen, den API Schlüssel als Abfrage zu akzeptieren. Der Abfrage muss den Namen „apiKey“ haben.

Das folgende Beispiel zeigt, wie der API Schlüssel als Abfrage übergeben wird:

GET /App Builder/rest/v1/sales/customers?apiKey=DLOo9sPS5slJEMHpXBFt3g HTTP/1.1
HOST: example.com:443
Accept: application/json

Beachten Sie, dass hier ein potenzieller Konflikt besteht. Bei Abfragen der REST- API werden Abfrage in der Regel Ressourcenfeldnamen zugeordnet. Wenn API Schlüssel als Abfrage übergeben werden können, dürfen Ressourcen kein Feld mit dem Namen „apiKey“ haben.

HTTPS vs. HTTP

Um Man-in-the-Middle-Angriffe zu verhindern, müssen API Schlüssel über eine sichere HTTPS-Verbindung übertragen werden. App Builder erzwingt dies, indem über HTTP übertragene API Schlüssel ignoriert werden.

In manchen Umgebungen kann die HTTPS-Verbindung jedoch vor dem Webserver beendet werden. In diesem Fall können Sicherheitsadministratoren die Option AllowUnsafeHttpConnections aktivieren, um App Builder zu zwingen, über unsichere HTTP-Verbindungen gesendete API Schlüssel zu akzeptieren.