HTTP v2-Verbindungsauthentifizierungstypen

Einführung

Bei der Konfiguration einer HTTP v2-Verbindung werden nach Auswahl des Authentifizierungstyps im Menü Authentication zusätzliche Felder verfügbar, die auf dieser Seite für jeden Typ beschrieben werden:

• API Key: Geben Sie ein API-Schlüssel-Wert-Paar an, das in Headern oder Abfrageparametern gesendet wird.

• AWS Signature: Geben Sie eine AWS-Zugriffschlüssel-ID, einen geheimen Zugriffschlüssel, eine Region, einen Service und ein Sitzungstoken an, um diese mit Amazon Web Services (AWS) Signature Version 4 in Headern oder Abfrageparametern zu senden.

• Basic Auth: Geben Sie einen Benutzernamen und ein Passwort an, die in Headern gesendet werden.

• Bearer Token: Geben Sie ein Bearer-Token an, das in Headern gesendet wird.

• Digest Auth: Geben Sie einen Benutzernamen, ein Passwort, einen Realm, einen Nonce, einen Algorithmus, QOP, eine Nonce-Anzahl, einen Client-Nonce und einen Opaque-Wert an, die in Headern gesendet werden.

• Hawk Authentication: Geben Sie eine Hawk-Authentifizierungs-ID, einen Authentifizierungsschlüssel, anwendungsspezifische Informationen, eine App-ID und DLG an, um diese in Headern zu senden.

• No Auth: Wählen Sie diese Option, um anonym auf den Service zuzugreifen, ohne Autorisierung.

• NTLM Authentication: Geben Sie einen Benutzernamen, ein Passwort, eine Domäne und eine Arbeitsstation an, die in Headern kompatibel mit dem Microsoft NTLM-Protokoll gesendet werden.

• OAuth 2.0: Geben Sie den Grant-Typ an und stellen Sie den OAuth-Token-Endpunkt, die Client-ID, das Client-Secret und den Scope bereit, um diese in Headern oder im Request-Body zu senden.

API Key

Wenn API Key im Menü Authentication ausgewählt wird, geben Sie den API-Schlüssel und den Wert an und wählen aus, ob das Schlüssel-Wert-Paar in Headern oder Abfrageparametern gesendet werden soll.

• Key: Geben Sie den API-Schlüssel ein.

• Value: Geben Sie den Wert des API-Schlüssels ein.

• Add To: Verwenden Sie das Menü, um entweder Headers oder Query Params auszuwählen:

  • Headers: Das API-Schlüssel-Wert-Paar wird mit dem definierten Request-Header-Schlüssel gesendet.

  • Query Params: Das API-Schlüssel-Wert-Paar wird mit Abfragestringparametern gesendet. Beispiel:

    GET /endpoint?api_key=abcdefgh123456789

AWS Signature

Wenn AWS Signature im Menü Authentication ausgewählt wird, geben Sie eine AWS-Zugriffschlüssel-ID, einen geheimen Zugriffschlüssel, eine Region, einen Service und ein Sitzungstoken an, um diese mit Amazon Web Services (AWS) Signature Version 4 in Headern oder Abfrageparametern zu senden.

• Access Key: Geben Sie die AWS-Zugangsschlüssel-ID ein. Beispiel: AKIAIOSFODNN7EXAMPLE.

• Secret Key: Geben Sie den AWS-Geheimzugangsschlüssel ein. Beispiel: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY.

• Add Authorization Data To: Wählen Sie Request Headers aus, um die Autorisierungsdaten über den HTTP-Header Authorization zu senden.

• Region: Geben Sie den AWS-Regionscode ein. Beispiel: us-east-1 für US East (N. Virginia).

• Service Name: Geben Sie den AWS-Service-Namespace ein (auch als AWS-Service-Präfix bekannt), der das AWS-Produkt identifiziert. Beispiel: s3 für Amazon S3.

• Session Token: Geben Sie das AWS-Session-Token ein, wenn die Anfrage mit temporären Sicherheitsanmeldeinformationen signiert wird. Beispiel: AQoDYXdzEJr...<Rest des Session-Tokens>.

Basic Auth

Wenn Basic Auth im Menü Authentication ausgewählt ist, werden die angegebenen Anmeldeinformationen über den HTTP-Header Authorization gesendet. Die Anmeldeinformationen werden automatisch Base64-codiert.

• Username: Geben Sie den Benutzernamen ein.

• Password: Geben Sie das Passwort ein.

Bearer Token

Wenn Bearer Token im Menü Authentication ausgewählt ist, wird das angegebene Bearer-Token über den HTTP-Header Authorization gesendet.

• Bearer Token: Geben Sie das Bearer-Token ein.

Digest Auth

Wenn Digest Auth im Menü Authentication ausgewählt ist, geben Sie einen Benutzernamen, ein Passwort, einen Realm, einen Nonce, einen Algorithmus, QOP, eine Nonce-Anzahl, einen Client-Nonce und einen Opaque-Wert an, um einen Hash zu generieren, der über die WWW-Authenticate-Direktive an den Service gesendet wird.

• Username: Geben Sie den Benutzernamen im angegebenen Realm ein.

• Password: Geben Sie das Passwort ein, das dem Benutzernamen zugeordnet ist.

• Realm: Geben Sie den Realm ein, der dem Benutzernamen und Passwort zugeordnet ist. Beispiel: registered_users@example.com.

• Nonce: Geben Sie den Server-Nonce ein.

• Algorithm: Geben Sie den Algorithmus ein, der zur Berechnung des Digest verwendet wird. Diese Algorithmen werden unterstützt:

  • MD5
  • MD5-sess
  • SHA-256
  • SHA-256-sess
  • SHA-512
  • SHA-512-sess

• QOP: Geben Sie ein Token ein, das eine einzelne Qualitätsstufe (QOP) angibt, die auf die Nachricht angewendet wird.

• Nonce Count: Geben Sie die hexadezimale Anzahl der Anfragen ein, die mit dem Client Nonce-Wert in dieser Anfrage gesendet wurden.

• Client Nonce: Geben Sie den Client-Nonce ein, einen ASCII-only-Zeichenfolgenwert.

• Opaque: Geben Sie eine Zeichenfolge mit Daten ein, die von nachfolgenden Anfragen mit URIs im gleichen Schutzbereich zurückgegeben werden sollen.

Hawk-Authentifizierung

Wenn Hawk Authentication im Menü Authentication ausgewählt wird, geben Sie die Hawk Authentifizierungs-ID, den Authentifizierungsschlüssel, anwendungsspezifische Informationen, eine App-ID und DLG an, die in Headern gesendet werden sollen.

• Hawk Auth ID: Geben Sie die API-Authentifizierungs-ID ein.

• Hawk Auth Key: Geben Sie den API-Authentifizierungsschlüssel ein.

• EXT: Geben Sie anwendungsspezifische Informationen ein, die mit der Anfrage gesendet werden sollen.

• App: Geben Sie die Anwendungs-ID ein.

• DLG: Wenn die Hawk Auth ID und der Hawk Auth Key durch Zugriffsdelegation erhalten werden, geben Sie die ID der delegierenden Anwendung ein.

Keine Authentifizierung

Wenn No Auth im Menü Authentication ausgewählt wird, greift die Verbindung anonym auf den Service zu.

NTLM-Authentifizierung

Wenn NTLM Authentication im Menü Authentication ausgewählt wird, geben Sie den Benutzernamen, das Passwort, die Domäne und die Arbeitsstation an, die in Headern kompatibel mit dem Microsoft NTLM-Protokoll gesendet werden sollen.

• Username: Geben Sie den Benutzernamen des Kontos ein.

• Password: Geben Sie das Passwort des Kontos ein.

• Domain: Geben Sie die dem Konto zugeordnete Domäne ein.

• Workstation: Geben Sie die dem Konto zugeordnete Arbeitsstation ein.

Weitere Informationen finden Sie in der Microsoft-Dokumentation zur NTLM-Benutzerauthentifizierung.

OAuth 2.0

Die in der HTTP v2-Verbindungskonfiguration verwendete Schnittstelle hängt von der ausgewählten Option OAuth type ab:

• Client Credentials Grant: Bei dieser Option wird die Verbindung mit 2-legged OAuth 2.0 authentifiziert.

• Authorization Code Grant: Bei dieser Option wird die Verbindung mit einer 3-legged OAuth 2.0-App authentifiziert. Diese Option erfordert die Verwendung von Cloud Agents oder Private Agent Version 10.83 / 11.21 oder später.

Client Credentials Grant

Wenn Client Credentials Grant als OAuth type ausgewählt wird, werden die folgenden Felder angezeigt.

• OAuth type: Wählen Sie Client Credentials Grant, um sich mit 2-legged OAuth 2.0 zu authentifizieren (siehe unten).

• Grant types: Verwenden Sie das Menü, um den zu verwendenden Grant-Type-Flow auszuwählen, entweder Client Credentials oder Password Grant:

  • Client Credentials: (Standard.) Der Client Credentials Grant Type.

  • Password Grant: Der Resource Owner Password Credentials Grant Type, der die Anmeldedaten eines Benutzers als Zugriffstoken verwendet. Wenn dieser Typ ausgewählt wird, werden zwei zusätzliche Felder verfügbar, um sie unten zu konfigurieren: Username und Password.

• OAuth-Token-Endpunkt: Geben Sie den Endpunkt als vollständige URL ein, die auf /oauth/token endet und zum Generieren des Tokens verwendet wird.

• Client-ID: Geben Sie die Client-ID ein, die der OAuth-Serviceanwendung zugeordnet ist.

• Client-Secret: Geben Sie das Client-Secret ein, das der OAuth-Serviceanwendung zugeordnet ist.

• Benutzername: Wenn der Grant-Typ Password Grant ausgewählt ist, geben Sie den Benutzernamen des Ressourcenbesitzers ein.

• Passwort: Wenn der Grant-Typ Password Grant ausgewählt ist, geben Sie das Passwort ein, das dem Benutzernamen zugeordnet ist.

• Scope: Geben Sie eine durch Leerzeichen getrennte Liste von Scope-Berechtigungen in dem Format ein, das der OAuth-Service erwartet. Beispiele: users, users.read, users:read, user-list-r, https://example.com/auth/scopes/user/users.readonly, openid profile usw.

• Grant-Typ-Anforderungsparameter: Wenn der Grant-Typ Client Credentials ausgewählt ist, verwenden Sie das Menü, um den grant_type-Wert auszuwählen, der in Token-Anforderungen gesendet werden soll: entweder Client Credentials oder Custom:

  • Client Credentials: (Standard.) Sendet client_credentials als grant_type-Wert.

  • Custom: Sendet den im Feld Custom grant type value eingegebenen Wert als grant_type-Wert. Verwenden Sie diese Option, wenn der OAuth-Service einen nicht standardmäßigen grant_type-Wert erfordert.

• Custom grant type value: Wenn Custom im Menü Grant type request parameter ausgewählt ist, geben Sie den benutzerdefinierten grant_type-Wert ein, der in Token-Anforderungen gesendet werden soll. Beispiel: account_credentials.

• Token-Typ: Geben Sie optional den Token-Typ des OAuth-Token-Endpunkts ein. Beispiele: bearer oder refresh.

• Client-Authentifizierung: Verwenden Sie das Menü, um entweder Send as Basic Auth Header oder Send Client Credentials in Body auszuwählen:

  • Send as Basic Auth Header: Die Autorisierungsdaten werden über den HTTP-Header Authorization gesendet.

  • Send Client Credentials in Body: Die Autorisierungsdaten werden im Body der Anforderung gesendet.

Authorization Code Grant

Wenn Authorization Code Grant als OAuth-Typ ausgewählt ist, werden die folgenden Felder angezeigt. Wichtige Hinweise zum Verhalten von Zugriffstoken und Aktualisierungstoken finden Sie unter Wichtige Hinweise.

• OAuth-Typ: Wählen Sie Authorization Code Grant aus, um sich mit einer 3-beinigen OAuth-2.0-Anwendung zu authentifizieren. Diese Option erfordert die Verwendung von Agent-Version 10.83 / 11.21 oder später.

• OAuth-Anwendung: Verwenden Sie das Menü, um eine private HTTP-v2-Connector-Anwendung auszuwählen, die in der Management Console auf der Seite App Registrations konfiguriert ist.

  Wenn für diesen Connector keine private Anwendung registriert wurde, ist das Menü leer und die Fehlermeldung No app registrations found for HTTP v2 wird angezeigt. Weitere Informationen zur Konfiguration einer privaten Anwendung finden Sie unter Connector 3-legged OAuth 2.0.

  Hinweis

  Informationen zum Verbinden mit NetSuites SuiteTalk REST-Webservices finden Sie unter 3-legged OAuth 2.0 (3LO) – Voraussetzungen für die Verbindung mit NetSuite für weitere Informationen.

• Mit OAuth anmelden: Klicken Sie, um sich über den Endpunkt in einem separaten Browser-Tab zu authentifizieren und Jitterbit die Berechtigung zum Zugriff auf die 3-beinige OAuth-App zu erteilen.

Stellen Sie beim Konfigurieren einer OAuth-Anwendung mit dem Endpunkt sicher, dass die Callback-URL (auch Callback-URI, Redirect-URL oder Redirection-URI usw. genannt) auf eine der folgenden URLs eingestellt ist (abhängig von der Region Ihrer Organisation):