Authentifizieren von HTTP-Integrationen
RGeschrieben vonRiku Virtanen Vor über einer Woche aktualisiertTable of contentsAuthentifizierung in HTTP-Integrationen
OAuth-Ablauf
OAuth (Open Authorization) ist ein offenes Standardframework zur Authentifizierung, das den sicheren gemeinsamen Zugriff auf Ressourcen ermöglicht. Normalerweise werden OAuth-Flows von Endbenutzern in Web-, Mobil- oder Desktopanwendungen verwendet, um über Authentifizierungsanbieter von Drittanbietern Zugriff zu erhalten, aber sie sind sicherlich auch in der Welt der Unternehmensintegrationen üblich. Der OAuth-Standard hat sich bis zur aktuellen Version 2.0 weiterentwickelt und bietet eine Reihe empfohlener Authentifizierungs-Flows, die für bestimmte Zwecke implementiert werden. Jetzt konzentrieren wir uns auf den OAuth-Flow der Version 2.0 (OAuth2), der für gängige Unternehmensintegrationsmuster geeignet ist und als Client Credentials Flow bezeichnet wird.
Im Client Credentials Flow übergibt der Client, beispielsweise Frends, ClientID und ClientSecret an den Autorisierungsserver oder Endpunkt, um Token zu erhalten, die den Zugriff auf entsprechende Ressourcen ermöglichen. Normalerweise stellt der Autorisierungsserver einen AccessToken für einen zeitlich begrenzten Zugriff und einen RefreshToken zum Abrufen neuer Token in einem längeren Zeitraum bereit. Der Ablauf wird in der folgenden Abbildung beschrieben.
Abhängig von der Implementierung des OAuth2-Client-Anmeldeinformationsflusses können die Nutzlast und die erforderlichen Anmeldeinformationen variieren, glücklicherweise werden diese jedoch normalerweise in der API-Dokumentation beschrieben.
Sehen wir uns ein Beispiel für die Verwendung eines Client Credentials Flow mit Frends für eine imaginäre GraphQL-API an, die folgende Eigenschaften aufweist:
AccessToken mit einer Ablaufzeit von 600 Sekunden und RefreshToken mit einer Ablaufzeit von 30 Tagen werden von imaginary.com/api/login mit ClientID und ClientSecret in der JSON-Nutzlast abgerufen.
Ein neuer AccessToken und RefreshToken können durch POST mit der Nutzlast {"refreshToken": "your_refresh_token"} an den Endpunkt imaginary.com/api/login/refresh angefordert werden.
Die GraphQL-Abfragen können mit dem HTTP-Header „Authorization: Bearer your_access_token“ an den Endpunkt imaginary.com/api/graphql gesendet werden.
Da es vorteilhaft wäre, diese Token vorübergehend zu speichern und immer einen gültigen AccessToken bereitzustellen, sollten wir zunächst einen wiederverwendbaren Subprozess für die Handhabung dieser Token erstellen. Indem wir diese Token mit der Shared State Task-Funktionalität speichern, erzielen wir eine höhere Leistung bei häufiger Nutzung im Vergleich dazu, immer einen neuen AccessToken pro GraphQL-Abfrage anzufordern, da die Datenbankabfragen des Shared State Tasks im Hintergrund viel schneller sind als HTTP-Anfragen an den Autorisierungsserver oder Endpunkt. Darüber hinaus vermeiden wir unnötigen Datenverkehr zum Autorisierungsserver und viele API-Dienstanbieter erwarten von den Verbrauchern, dass sie AccessTokens und RefreshTokens so oft wie möglich wiederverwenden.
Ein Ansatz besteht darin, einen folgenden Unterprozess zu erstellen, der immer dann aufgerufen wird, wenn ein Prozess ein AccessToken für die GraphQL-Abfrage erfordert.
Der erste Shared State Task würde versuchen, den AccessToken abzurufen mitBei einem Fehler eine Ausnahme auslösenParameter nicht umgeschaltet. Die Exklusiventscheidung danach würde dann prüfen, ob der AccessToken verfügbar war mit#Ergebnis[Versuchen Sie, Zugriffstoken abzurufen].ErfolgAusdruck und mit der Auswertung als wahr würde der Unterprozess das Ergebnis der Shared State Task mit der Eigenschaft zurückgebenWertfür den eigentlichen AccessToken. Wenn der AccessToken nicht abgerufen werden konnte, würde die Exclusive Decision zu einer Shared State Task übergehen, die versucht, einen RefreshToken auf ähnliche Weise abzurufen wie zuvor mit dem AccessToken. Abhängig von der nächsten Auswertung des Exclusive Decision Expression würde der Subprozess die RestRequest Task mit dem abgerufenen RefreshToken verwenden, um neue Token abzurufen, oder die RestRequest Task mit den Client Credentials verwenden, um insgesamt neue Token anzufordern. Die Client Credentials von ClientID und ClientSecret würden in Frends-Umgebungsvariablen gespeichert und in der RestRequest Task referenziert. Die Ergebnisse aus beiden Zweigen würden im Codeelement zusammengeführt.Körper zuweisenfür die Zuweisung#var.Bodymit den HTTP-Antworten, die neue Token enthalten. Schließlich werden RefreshToken und AccessToken mit Shared State Tasks hinzugefügt oder aktualisiert, wodurch der Subprozess mit einem Ergebnis endet, das die Eigenschaft enthältWertdas ist das gültige AccessToken. Im aufrufenden Subprozess oder Prozess würde die korrekte Referenz für AccessToken schließlich so aussehen:#result[Name dieses Unterprozesses].Wert.
Nachdem wir nun den AccessToken abrufen können, können wir die GraphQL-API mit dem HTTP-Header „Authorization: Bearer #{{#result[this subprocess name].Value}} aufrufen.
Diese Art von OAuth2-Flow ist in REST- und GraphQL-APIs sehr verbreitet.
API-Schlüssel
API-Schlüssel sind ebenfalls eine gängige Methode zur Authentifizierung, bieten jedoch aufgrund der Einfachheit der API-Schlüsselauthentifizierung nicht die gleiche Sicherheit wie OAuth2-Flows. API-Schlüssel sind Zeichenfolgen, die üblicherweise in einem bestimmten HTTP-Header einer Anfrage übergeben werden, und jeder, der diese Schlüssel verwendet, kann Zugriff auf Ressourcen erhalten, die für den bestimmten Schlüssel gewährt werden. Ein HTTP-Header eines API-Schlüssels könnte wie folgt aussehen: X-API-KEY: abcdefg098765. Die Dokumentation der API sollte ausführlich erläutern, wie die API-Schlüssel verwendet werden sollen, und die Implementierung mit Frends HTTP Tasks ist ziemlich einfach.
Sehen wir uns ein Beispiel für eine REST-API an, die einen Hund als Ressource darstellt und die Authentifizierung über einen API-Schlüssel abwickelt. Der API-Schlüssel, der eine zufällige Zeichenfolge enthält, muss in einem HTTP-Header mit dem Namen X-API-KEY übergeben werden. Die API gibt Daten im JSON-Format zurück.
In der Implementierung würden wir die RestRequest-Aufgabe verwenden und die Parameter wie im folgenden Bild konfigurieren. Der API-Schlüssel selbst würde aus Umgebungsvariablen referenziert und als Geheimnis behandelt.
Denken Sie daran, die Dokumentation der verwendeten API auf den korrekten HTTP-Headernamen zu prüfen, da diese variieren können.
Grundlegende Authentifizierung
Die Basisauthentifizierung ist API-Schlüsseln sehr ähnlich, da die Authentifizierungsmethode auf einem Geheimnis im HTTP-Header basiert. Bei der Basisauthentifizierung hat der Header die Form Autorisierung: Basic „base64encode(Benutzername:Passwort)“, wobei Benutzername und Passwort mit einem Doppelpunkt (:) verbunden und base64-codiert sind.
Basic Auth kann mit Frends auf zwei Arten implementiert werden: Sie können den Autorisierungsheader selbst erstellen oder die Authentifizierungsoption von HTTP-Anforderungsaufgaben verwenden.Basic. Beides führt zu einem korrekten Basic Auth-HTTP-Header für die HTTP-Anfrage, aber die Verwendung der integrierten Task Basic Authentication ist sicherlich einfacher.
In den folgenden Beispielen wurden beide Ansätze mit denselben Verweisen auf die Umgebungsvariablen für Benutzername und Passwort implementiert.
Verwenden der integrierten Basisauthentifizierungsparameter:
Ohne die Task-Optionen zu verwenden und den HTTP-Header manuell zu bilden:
Gegenseitige Authentifizierung mit Zertifikaten
Bei einer HTTP-Anfrage können Client und Server eine gegenseitige Authentifizierung mit Zertifikaten verwenden, was bedeutet, dass der Client auch ein Zertifikat zur Authentifizierung gegenüber dem Server bereitstellt. Dies kann durch die Verwendung der Authentifizierungsoption von Frends HTTP Tasks erreicht werden.Client-Zertifikat.
Der folgende Screenshot einer Registerkarte „Aufgabenoptionen“ zeigt die erforderlichen Parameter für die ClientCertificate-Authentifizierung.
Der Entwickler muss auswählen, woher er das öffentliche Schlüsselzertifikat für einen bestimmten HTTP-Server in dieser spezifischen HTTP-Anforderung bezieht,Client-Zertifikatquelle (CertificateStore/File/String)da die Zertifikate im Frends Agent Certificate Store, in einer Datei auf einem Laufwerk oder in einem String-Format gespeichert werden können. Die folgenden Parameter hängen von der Auswahl vonClient-Zertifikatquelle. WannZertifikatsspeicherverwendet wird, muss der Entwickler festlegenFingerabdruck des Zertifikatswelches das richtige Zertifikat aus dem Speicher auswählt. MitDateials Quelle, dieDateipfad des Client-Zertifikatsmuss mit dem Pfad auf dem Frends Agent-Laufwerk für die PFX-Datei (pkcs12) konfiguriert werden. WennZeichenfolgeals Quelle verwendet wird, muss die Client-Zertifikatsdatei in eine Base64-Darstellung des Byte-Arrays konvertiert werden. BeideDateiUndZeichenfolgeerfordern auch dieSchlüsselphrase für Client-Zertifikatfür den Zugriff auf die Zertifikatsdaten.
Der nächste Artikel istEinführung in die Structured Query Language (SQL)
Verwandte ArtikelHTTP-TriggerEinführung in Integrationen mit HTTPEinführung in andere Techniken für HTTP-AnfragenEinführung in die API-AuthentifizierungEinführung in die API-Authentifizierung mit Frends