Viele APIs erfordern, dass der Aufrufende Authentifizierungsinformationen angibt, um die Identität – und möglicherweise die Zugriffsberechtigungen – des Aufrufenden zu verifizieren. Authentifizierungsinformation können über den HTTP-Header (Basic/NTLM/Digest-Authentifizierung), durch Austausch von Zugriffs-Tokens (OAuth), indem vom Client die Mitgabe eines Client-Zertifikats in der Anfrage erwartet wird oder eine Kombination davon weitergegeben werden.  

Dieser Artikel behandelt die HTTP-Header- und Token-basierten Authentifizierungsmethoden bei Uptrends. Um Client-Zertifikate einzurichten, lies bitte den Artikel zur Client-Zertifikats-Authentifizierung

Standard-Authentifizierungsarten

Der Abschnitt Authentifizierung auf der Registerkarte Request bei einem Multi-step API Monitoring-Prüfobjekt stellt mehrere Authentifizierungsarten bereit. Bei allen wird eine Kombination aus Benutzername/Passwort verwendet. Wie diese Anmeldeinformationen verarbeitet und an die API gesendet werden, unterscheidet sich je nach Art:

  • Basic Authentication: Benutzername und Passwort sind in einem einfachen Base64-Format verschlüsselt und werden an den API-Server gesendet.
  • NTLM (Windows) Authentication: Wenn Du diesen Typ wählst, werden mehrere Anfragen an die API gesendet, um die zu verwendende Authentifizierung zu verhandeln, bevor die letztendliche HTTP-Anfrage mit der entsprechenden Authentifizierung gesendet wird. Diese Reihe von Anfragen wird als ein einzelner Schritt betrachtet. Wenn eine Windows-Domain angegeben werden muss, schließe sie im Benutzernamen ein: YOURDOMAIN\username
  • Digest Authentication:  Bei Auswahl dieses Typs senden wir zwei aufeinanderfolgende Anfragen an die API. Die erste Anfrage sendet eine Anfrage ohne Authentifizierungsdaten und erwartet, dass der Server Authentifizierungsanweisungen im WWW-Authentifizierungs-Antwort-Header zurückgibt. Der Benutzername und Passwort werden gemäß diesen Anweisungen mit einem Hash versehen (einschließlich nonce- und qop-Werten) und mit der zweiten Anfrage gesendet, die dann richtig authentifiziert wird. Diese Reihe von Anfragen wird als ein einzelner Schritt betrachtet.
  • None: Wähle None, wenn Du keine Authentifizierung für Deine HTTP-Anfrage nutzt.

HTTP-Header

Wenn Du eine dieser Authentifizierungsarten nutzt, musst Du keine weiteren authentifizierungsspezifischen HTTP-Header angeben: Wir werden die entsprechenden Autorisierungs-Header für Dich erzeugen.

Variablen-Support

Benutzername- und Passwort-Felder unterstützen Variablen. Du kannst vordefinierte Variablen (zum Beispiel: {{username}} und {{password}}) mit den passenden Werten erstellen und dann diese Variablennamen in den Authentifizierungsfeldern verwenden. Weitere Informationen über Variablen und vordefinierte Variablen.

Benutzerdefinierte Authentifizierung (einschließlich OAuth)

Wenn Deine API OAuth als Authentifizierungsprotokoll nutzt, benötigst Du ein ausgefeilteres Setup. Abhängig von Deiner API benötigst Du möglicherweise etwas Spezielles für die Situation. OAuth 2.0 insbesondere nutzt eine separate Anfrage für den Authentifizierungsprozess. Diese Anfrage benötigt Zugang zur API (anhand einer Standard-Authentifizierungsart durch Spezifizieren von Anmeldedaten in der URL oder Ausführen einer Webseitenanmeldung). Nach erfolgreicher Authentifizierung wird das OAuth-Access-Token verzeichnet und in einer Variable gespeichert, sodass es in nachfolgenden Anfragen genutzt werden kann.

Wenn Du nicht OAuth, sondern ein anderes Protokoll verwendest, kann dies immer noch auf ähnliche Weise funktionieren: Du musst die Anmeldedaten angeben, die Deine Identität für die API „beweisen“. Der API-Server antwortet dann mit einem Anmelde-Token, das für eine bestimmte Dauer gültig ist. Durch Aufzeichnung dieses Tokens und Speicherung in einer Variablen kannst Du eine Reihe von Anfragen ausführen, die dieses Anmelde-Token verwenden, um Zugang zu erhalten.

Einrichtung der OAuth 2.0 Authentifizierung

Im folgenden Beispiel richten wir eine einfache OAuth 2.0 Authentifizierung ein. Unser Ziel besteht darin, ein Zugangstoken von der API zu erhalten, das wir in späteren Anfragen verwenden können.

Dafür werden wir eine Anfrage senden, die die entsprechenden OAuth-Felder enthält. In diesem Fall bitten wir um Zugang auf Basis eines Autorisierungscodes, einer Client-ID und eines Client-Geheimnisses. Die Client-ID und das Client-Geheimnis sind feststehende Werte, die wir als vordefinierte Variablen bestimmen können. In unserem einfachen Setup wird der Autorisierungscode ein fester Wert sein, aber in Deinem Setup kann es notwendig sein, den Autorisierungscode zunächst in einem separaten Schritt abzufragen.

Zuerst fügen wir diese Werte zu den vordefinierten Variablen hinzu:

Mit diesen definierten Variablen können wir nun eine Anfrage an unsere API einrichten, um Bezüge zu diesen Variablen einzuschließen, zusammen mit anderen Parametern, die von der API erwartet werden. Im ersten Schritt der mehrstufigen Einrichtung sollte diese URL enthalten sein:

GET https://myapi.com/oauth/token?grant_type=authorization_code&code={{authorizationcode}}&client_id={{clientid}}&client_secret={{clientsecret}}

Wir erwarten, dass die API eine Datenstruktur zurückgibt, die das benötigte Access-Token enthält, aber wie wird diese Datenstruktur formatiert sein? Um zu gewährleisten, dass wir JSON-formatierte Daten erhalten, werden wir dem Server sagen, dass wir nur das Format application/json annehmen, indem wir den HTTP-Header angeben:

Mit dem spezifizierten Header können wir nun erwarten, dass die Antwort wie Folgendes aussieht:

{
  "access_token":"SGV5ISBZb3UgZm91bmQgdGhpcyB0ZXh0IQ==",
  "token_type":"Bearer",
  "expires_in":86400
}

Alles, was wir nun tun müssen, ist das Feld access_token in der JSON-Antwort aufzuzeichnen. Dafür erzeugen wir eine neue Variable auf der Registerkarte Response bei unserem Schritt:

  • Die Antwort sollte JSON enthalten, wähle daher Response body as JSON als Quelle für die Variable.
  • Da das access_token-Attribut sich auf oberster Ebene in unserer Datenstruktur befindet, ist unser JSON-Ausdruck einfach access_token.
  • Wir wählen accesstoken als Namen unserer Variablen. Auf diesen Namen beziehen wir uns bei späteren Schritten.

Obwohl das Hauptziel dieses ersten Schrittes darin besteht, das Access-Token aufzuzeichnen, wird bereits ein Monitoring ausgeführt: Wenn die API zu diesem Zeitpunkt einen Fehler registriert oder wenn die Antwort kein Access-Token enthält, wird das in diesem Schritt bemerkt und ein Fehler gemeldet.

Da wir nun ein gültiges Access-Token haben, können wir schließlich auf die tatsächliche API-Methode zugreifen, die wir prüfen möchten (und zum Beispiel eine Liste von Produkten abrufen). Erstelle einen neuen Schritt, um diesen API-Aufruf zu definieren. Nach Spezifizieren der Methode und URL für diese neue Anfrage, geben wir das Access-Token ein, das wir gerade aufgezeichnet haben. APIs basierend OAuth 2.0 erwarten einen HTTP-Header namens Authorization mit einem Wert Bearer {{accesstoken}}

Wir können dies für jeden zusätzlichen Schritt wiederholen, der dasselbe Access-Token benötigt.