TsgcHTTP_OAuth2_Client

Diese Komponente ermöglicht es Ihnen, den Ablauf zwischen Client und den anderen Rollen zu handhaben: Wenn Sie Active := True setzen, wird ein neuer Webbrowser geöffnet und der Benutzer wird zur Erteilung der Autorisierung aufgefordert. Bei Erfolg sendet der Autorisierungsserver ein Token an die Anwendung, das verarbeitet wird, und mit diesem Token kann sich der Client mit dem Ressourcenserver verbinden. Diese Komponente startet einen einfachen HTTP-Server, der die Antworten des Autorisierungsservers verarbeitet, und verwendet einen HTTP-Client, um Access-Tokens anzufordern.

 

GrantType

 

Der Client unterstützt die folgenden Arten der Autorisierung:

 

auth2Code: Wird verwendet, um Authentifizierung und Autorisierung in den meisten Anwendungstypen durchzuführen, einschließlich Single-Page-Anwendungen, Webanwendungen und nativ installierten Anwendungen. Der Ablauf ermöglicht es Apps, sicher access_tokens zu erwerben, die für den Zugriff auf gesicherte Ressourcen verwendet werden können, sowie Refresh Tokens, um zusätzliche access_tokens zu erhalten, und ID-Tokens für den angemeldeten Benutzer.

 

 

auth2CodePKCE: Es ist derselbe Authentifizierungsablauf wie auth2Code mit aktiviertem PKCE. PKCE (Proof Key for Code Exchange) ist eine Sicherheitserweiterung für OAuth 2.0, die entwickelt wurde, um die Sicherheit von Autorisierungsabläufen für native und Single-Page-Anwendungen zu erhöhen. Sie mindert das Risiko von Abfangangriffen, insbesondere bei öffentlichen Clients, bei denen der Autorisierungscode während der Übertragung abgefangen werden könnte. Üblicherweise wird diese Option in nativen und mobilen Apps verwendet.

 

auth2ClientCredentials: Dieser Grant-Typ wird üblicherweise für Server-zu-Server-Interaktionen verwendet, die im Hintergrund ausgeführt werden müssen, ohne unmittelbare Interaktion mit einem Benutzer. Diese Arten von Anwendungen werden oft als Daemons oder Dienstkonten bezeichnet.

 

 

auth2DeviceCode: Device Authorization Grant (RFC 8628) für eingabebeschränkte Geräte wie Smart-TVs, Medienkonsolen und IoT-Geräte, die keinen Browser haben oder über begrenzte Eingabefähigkeiten verfügen. Das Gerät zeigt einen User Code und eine Verification URI an; der Benutzer besucht die URI auf einem sekundären Gerät (Telefon oder Computer) und gibt den Code zur Autorisierung ein.

 

LocalServerOptions

 

Wenn ein Client ein neues Access Token benötigt, wird automatisch ein HTTP-Server gestartet, um die Antwort vom Autorisierungsserver zu verarbeiten. Dieser Server ist für den Benutzer transparent und arbeitet normalerweise auf localhost. Standardmäßig wird Port 8080 verwendet, den Sie aber bei Bedarf ändern können.

 

• IP: IP, an der der Server lauscht, Beispiel: 127.0.0.1
• Port: standardmäßig 8080. Bei Verwendung von GrantType = auth2CodePKCE (für Desktop- und native Anwendungen) können Sie den Wert des Ports auf null setzen, und der Server wählt einen zufälligen Port.
• RedirectURL: (optional) ermöglicht das Anpassen der Redirect-URL, Beispiel: http://localhost:8080/oauth/.
• SSL: Aktivieren Sie diese Eigenschaft, wenn der lokale Server auf einem sicheren Port läuft (*nur von Professional- und Enterprise-Editionen unterstützt).
• SSLOptions: ermöglicht das Anpassen der SSL-Eigenschaften des Servers (*nur von der Professional- und Enterprise-Edition unterstützt).
• LogOptions: ermöglicht es Ihnen, das Protokoll der vom internen HTTP-Server empfangenen und gesendeten Requests/Responses zu speichern (*Nur für Professional- und Enterprise-Editionen).
  • Enabled: auf True setzen, um die Protokollierung in eine Datei zu aktivieren.
  • FileName: Dateiname zum Speichern der Protokolldatei festlegen.

 

AuthorizationServerOptions

 

Hier müssen Sie die URL für Authorization und Access Token festlegen, üblicherweise werden diese in der API-Spezifikation bereitgestellt. Scope ist eine Liste aller vom Client angeforderten Scopes. Beispiel:

 

• AuthURL: https://accounts.google.com/o/oauth2/auth
• TokenURL: https://accounts.google.com/o/oauth2/token
• Scope: https://mail.google.com/
• RevocationURL: URL für den Token-Revocation-Endpunkt (erforderlich für die Revoke-Methode). Beispiel: https://accounts.google.com/o/oauth2/revoke
• IntrospectionURL: URL für den Token-Introspection-Endpunkt (erforderlich für die Introspect-Methode). Beispiel: https://accounts.google.com/o/oauth2/introspect

 

OAuth2Options

 

ClientId ist ein Pflichtfeld, das dem Server die Identifikation des Clients mitteilt. Prüfen Sie Ihre API-Spezifikation, um zu erfahren, wie Sie eine ClientId erhalten. Dasselbe gilt für das Client-Secret.

Manchmal erfordert der Server einen Benutzer und ein Passwort, um sich über Basic Authentication zu verbinden; wenn dies der Fall ist, können Sie dies in den Feldern Username/Password einrichten. Beispiel:

 

• GrantType: Autorisierungsablauf-Typ
  • auth2Code: vertrauenswürdige Apps, wie ein Webserver.
  • auth2CodePKCE: nicht vertrauenswürdige native oder mobile Apps.
  • auth2ClientCredentials: automatisierte Apps ohne Benutzerinteraktion.
  • auth2ResourceOwnerPassword: ermöglicht es einer Anwendung, den Benutzer anzumelden, indem sie direkt sein Passwort verarbeitet
  • auth2DeviceCode: Device Authorization Grant (RFC 8628) für eingabebeschränkte Geräte ohne Browser oder mit begrenzten Eingabefähigkeiten.
• ClientId: 180803918307-eqjtm20gqfhcs6gjklbbrreng022mqqc.apps.googleusercontent.com
• ClientSecret: _by1iYYrvVHxC2Z8TbtNEYJN
• Username:
• Password:

 

HTTPClientOptions

 

Hier können Sie die Client-Optionen anpassen, wenn die Verbindung zum HTTP-Server hergestellt wird, um ein neues Token anzufordern.

 

TLSOptions: wenn TLS aktiviert ist, können Sie hier einige TLS-Eigenschaften anpassen.

 

ALPNProtocols: Liste der ALPN-Protokolle, die an den Server gesendet werden.

RootCertFile: Pfad zur Root-Zertifikatdatei.

CertFile: Pfad zur Zertifikatsdatei.

KeyFile: Pfad zur Zertifikatsschlüsseldatei.

Password: wenn das Zertifikat mit einem Passwort gesichert ist, setzen Sie es hier.

VerifyCertificate: wenn das Zertifikat überprüft werden muss, aktivieren Sie diese Eigenschaft.

VerifyDepth: ist eine Integer-Eigenschaft, die die maximale Anzahl von Verknüpfungen darstellt, die zulässig sind, wenn die Überprüfung für das X.509-Zertifikat durchgeführt wird.

Version: Verwendet standardmäßig TLS 1.0; wenn der Server eine höhere TLS-Version erfordert, kann diese hier ausgewählt werden.

IOHandler: wählen Sie aus, welche Bibliothek Sie zur Verbindung über TLS verwenden.

iohOpenSSL: verwendet die OpenSSL-Bibliothek und ist der Standard für Indy-Komponenten. Erfordert das Bereitstellen der OpenSSL-Bibliotheken für win32/win64.

iohSChannel: verwendet Secure Channel, ein von Microsoft für Windows implementiertes Sicherheitsprotokoll, das die Bereitstellung von OpenSSL-Bibliotheken nicht erfordert. Funktioniert nur unter Windows 32/64 Bit.

OpenSSL_Options: ermöglicht die Definition, welche OpenSSL-API verwendet wird.

APIVersion: ermöglicht die Definition, welche OpenSSL-API verwendet wird.

oslAPI_1_0: verwendet API 1.0 OpenSSL, es ist die neueste von Indy unterstützte

oslAPI_1_1: verwendet API-1.1-OpenSSL, erfordert unsere benutzerdefinierte Indy-Bibliothek und ermöglicht die Verwendung von OpenSSL-1.1.1-Bibliotheken (mit TLS-1.3-Unterstützung).

oslAPI_3_0: verwendet API 3.0 OpenSSL, erfordert unsere benutzerdefinierte Indy-Bibliothek und ermöglicht die Verwendung von OpenSSL-3.0.0-Bibliotheken (mit TLS-1.3-Unterstützung).

LibPath: hier können Sie konfigurieren, wo sich die openSSL-Bibliotheken befinden

oslpNone: dies ist der Standard, die OpenSSL-Bibliotheken sollten sich im selben Ordner befinden, in dem sich die Binärdatei befindet, oder in einem bekannten Pfad.

oslpDefaultFolder: legt automatisch den OpenSSL-Pfad fest, in dem sich die Bibliotheken für alle IDE-Personalities befinden sollten.

oslpCustomFolder: wenn dies die ausgewählte Option ist, definieren Sie den vollständigen Pfad in der Eigenschaft LibPathCustom.

LibPathCustom: wenn LibPath = oslpCustomFolder, definieren Sie hier den vollständigen Pfad, in dem sich die OpenSSL-Bibliotheken befinden.

UnixSymLinks: aktiviert oder deaktiviert das Laden von SymLinks unter Unix-Systemen (standardmäßig aktiviert, außer unter OSX64):

oslsSymLinksDefault: standardmäßig aktiviert, außer unter OSX64 (nach MacOS Monterey schlägt der Versuch fehl, die Bibliothek ohne Version zu laden.).

oslsSymLinksLoadFirst: SymLinks laden und vor dem Versuch, die Versionsbibliotheken zu laden, ausführen.

oslsSymLinksLoad: Lädt SymLinks, nachdem versucht wurde, die Versionsbibliotheken zu laden.

oslsSymLinksDontLoad: lädt die SymLinks nicht.

SChannel_Options: ermöglicht die Verwendung eines Zertifikats aus dem Windows-Zertifikatspeicher.

CertHash: ist der Zertifikats-Hash. Sie können den Zertifikats-Hash finden, indem Sie einen dir-Befehl in PowerShell ausführen.

CertStoreName: der Speichername, in dem das Zertifikat abgelegt ist. Wählen Sie einen der folgenden aus:

scsnMY (der Standardwert)

scsnCA

scsnRoot

scsnTrust

CertStorePath: der Store-Pfad, unter dem das Zertifikat gespeichert ist. Wählen Sie einen der folgenden aus:

scspStoreCurrentUser (der Standard)

scspStoreLocalMachine

 

LogOptions: Wenn ein Dateiname festgelegt ist, wird ein Protokoll der HTTP-Anfragen/-Antworten des HTTP-Clients gespeichert