TsgcHTTP_OAuth2_Client
Cliquez ici pour afficher cette page dans son contexte complet

TsgcHTTP_OAuth2_Client

Lorsqu'un client a besoin d'un nouveau jeton d'accès, démarre automatiquement un serveur HTTP pour traiter la réponse du serveur d'autorisation.

Introduction

Ce composant vous permet de gérer le flux entre le client et les autres rôles, essentiellement, lorsque vous définissez Active := True, il ouvre un nouveau navigateur Web et demande à l'utilisateur d'accorder l'autorisation, si c'est réussi, le serveur d'autorisation envoie un jeton à l'application qui est traité et avec ce jeton, le client peut se connecter au serveur de ressources. Ce composant démarre un serveur HTTP simple qui gère les réponses du serveur d'autorisation et utilise un client HTTP pour demander des jetons d'accès.

 

GrantType

 

Le client prend en charge les types d'autorisation suivants :

 

auth2Code : Il est utilisé pour effectuer l'authentification et l'autorisation dans la majorité des types d'applications, y compris les applications à page unique, les applications web et les applications installées nativement. Le flux permet aux applications d'acquérir de manière sécurisée des access_tokens pouvant être utilisés pour accéder à des ressources sécurisées, ainsi que des tokens de rafraîchissement pour obtenir des access_tokens supplémentaires, et des ID tokens pour l'utilisateur connecté.

 

 

auth2CodePKCE : il s'agit du même flux d'authentification que auth2Code avec PKCE activé. PKCE (Proof Key for Code Exchange) est une extension de sécurité pour OAuth 2.0, conçue pour améliorer la sécurité des flux d'autorisation pour les applications natives et à page unique. Elle atténue le risque d'attaques par interception, notamment dans les clients publics où le code d'autorisation peut être exposé à l'interception en transit. Cette option est généralement utilisée dans les applications natives et mobiles.

 

auth2ClientCredentials : Ce type d'octroi est couramment utilisé pour les interactions serveur à serveur qui doivent s'exécuter en arrière-plan, sans interaction immédiate avec un utilisateur. Ces types d'applications sont souvent appelés démons ou comptes de service.

 

 

auth2DeviceCode : Autorisation de dispositif (RFC 8628) pour les appareils à saisie limitée tels que les téléviseurs connectés, les consoles multimédia et les appareils IoT dépourvus de navigateur ou dotés de capacités de saisie réduites. L'appareil affiche un code utilisateur et un URI de vérification ; l'utilisateur visite l'URI depuis un autre appareil (téléphone ou ordinateur) et saisit le code pour autoriser l'accès.

 

LocalServerOptions

 

Lorsqu'un client a besoin d'un nouveau jeton d'accès, un serveur HTTP est automatiquement démarré pour traiter la réponse du serveur d'autorisation. Ce serveur est transparent pour l'utilisateur et fonctionne généralement en localhost. Par défaut, il utilise le port 8080 mais vous pouvez le modifier si nécessaire.

 

 

AuthorizationServerOptions

 

Ici vous devez définir l'URL pour l'autorisation et le jeton d'accès, généralement fournis dans la spécification de l'API. Scope est la liste de tous les scopes demandés par le client. Exemple :

 

 

OAuth2Options

 

ClientId est un champ obligatoire qui indique au serveur l'identification du client. Consultez votre spécification API pour savoir comment obtenir un ClientId. Il en va de même pour le secret client.

Parfois, le serveur requiert un utilisateur et un mot de passe pour se connecter en utilisant l'authentification de base ; si c'est le cas, vous pouvez le configurer dans les champs Username/Password. Exemple :

 

 

HTTPClientOptions

 

Ici vous pouvez personnaliser les options Client lors de la connexion au serveur HTTP pour demander un nouveau jeton.

 

TLSOptions : si TLS est activé, vous pouvez personnaliser ici certaines propriétés TLS.

 

ALPNProtocols : liste des protocoles ALPN qui seront envoyés au serveur.

RootCertFile : chemin vers le fichier de certificat racine.

CertFile : chemin vers le fichier de certificat.

KeyFile : chemin vers le fichier de clé du certificat.

Password : si le certificat est protégé par un mot de passe, définissez-le ici.

VerifyCertificate : si le certificat doit être vérifié, activez cette propriété.

VerifyDepth : est une propriété Integer représentant le nombre maximum de liens autorisés lors de la vérification du certificat X.509.

Version : par défaut utilise TLS 1.0 ; si le serveur nécessite une version TLS supérieure, elle peut être sélectionnée ici.

IOHandler : sélectionnez la bibliothèque que vous utiliserez pour vous connecter via TLS.

iohOpenSSL: utilise la bibliothèque OpenSSL et est la valeur par défaut pour les composants Indy. Nécessite le déploiement des bibliothèques openssl pour win32/win64.

iohSChannel : utilise Secure Channel qui est un protocole de sécurité implémenté par Microsoft pour Windows, ne nécessite pas de déployer des bibliothèques openssl. Fonctionne uniquement en Windows 32/64 bits.

OpenSSL_Options: permet de définir quelle API OpenSSL sera utilisée.

APIVersion : permet de définir quelle API OpenSSL sera utilisée.

oslAPI_1_0 : utilise l'API 1.0 OpenSSL, la dernière version prise en charge par Indy

oslAPI_1_1 : utilise l'API 1.1 OpenSSL, nécessite notre bibliothèque Indy personnalisée et permet d'utiliser les bibliothèques OpenSSL 1.1.1 (avec prise en charge de TLS 1.3).

oslAPI_3_0 : utilise l'API OpenSSL 3.0, nécessite notre bibliothèque Indy personnalisée et permet d'utiliser les bibliothèques OpenSSL 3.0.0 (avec prise en charge de TLS 1.3).

LibPath : ici vous pouvez configurer l'emplacement des bibliothèques openSSL

oslpNone : c'est la valeur par défaut ; les bibliothèques OpenSSL doivent se trouver dans le même dossier que le binaire ou dans un chemin connu.

oslpDefaultFolder : définit automatiquement le chemin openSSL où les bibliothèques doivent être situées pour toutes les personnalités de l'IDE.

oslpCustomFolder : si cette option est sélectionnée, définissez le chemin complet dans la propriété LibPathCustom.

LibPathCustom : lorsque LibPath = oslpCustomFolder, définissez ici le chemin complet où se trouvent les bibliothèques openSSL.

UnixSymLinks : activer ou désactiver le chargement des liens symboliques sous les systèmes Unix (activé par défaut, sauf sous OSX64) :

oslsSymLinksDefault : activés par défaut sauf sous OSX64 (après MacOS Monterey, le chargement de la bibliothèque sans version échoue.).

oslsSymLinksLoadFirst : Charger d'abord les liens symboliques avant de tenter de charger les bibliothèques de version.

oslsSymLinksLoad : Charger les liens symboliques après avoir tenté de charger les bibliothèques de version.

oslsSymLinksDontLoad : ne pas charger les SymLinks.

SChannel_Options : vous permet d'utiliser un certificat depuis le magasin de certificats Windows.

CertHash : il s'agit du hachage du certificat. Vous pouvez trouver le hachage du certificat en exécutant une commande dir dans PowerShell.

CertStoreName : le nom du magasin où le certificat est stocké. Sélectionnez l'un des éléments suivants :

scsnMY (la valeur par défaut)

scsnCA

scsnRoot

scsnTrust

CertStorePath : le chemin du magasin où est stocké le certificat. Sélectionnez l'une des valeurs ci-dessous :

scspStoreCurrentUser (valeur par défaut)

scspStoreLocalMachine

 

LogOptions : si un nom de fichier est défini, il enregistrera un journal des requêtes/réponses HTTP du client HTTP

 

Référence