TsgcWSAPIServer_WebAuthn

Le composant TsgcWSAPIServer_WebAuthn fournit une solution simple mais puissante pour implémenter le serveur de partie de confiance WebAuthn, permettant une authentification sans mot de passe dans votre application web. Une application WebAuthn se compose d'un serveur WebAuthn qui gère l'inscription et l'authentification côté serveur, et d'une application côté client qui est généralement une application JavaScript.

 

WebAuthn nécessite l'utilisation de connexions sécurisées (SSL/TLS), donc les bibliothèques OpenSSL doivent être déployées et configurées avec le serveur.

 

Seule l'API OpenSSL 3.0.0+ est prise en charge, les versions précédentes d'OpenSSL peuvent ne pas fonctionner.

 

Configuration

 

Le TsgcWSAPIServer_WebAuthn doit être attaché à un serveur HTTP, TsgcWebSocketHTTP_Server ou TsgcWebSocketServer_HTTPAPI, en utilisant la propriété Server. Vous pouvez configurer les points de terminaison du serveur qui géreront les options d'enregistrement et d'authentification, ainsi que les options WebAuthn telles que les algorithmes pris en charge, les origines, et plus encore.

 

Options des points de terminaison

Ici vous pouvez configurer les points de terminaison du serveur qui géreront les requêtes HTTP/JavaScript pour utiliser WebAuthn comme authentificateur. Le composant est déjà configuré avec des points de terminaison par défaut, mais vous pouvez tous les modifier selon vos besoins.

 

• AuthenticationOptions : par défaut /sgcWebAuthn/Authentication/Options
• AuthenticationVerify : par défaut /sgcWebAuthn/Authentication/Verify
• RegistrationOptions : par défaut est /sgcWebAuthn/Registration/Options
• RegistrationVerify: par défaut /sgcWebAuthn/Registration/Verify
• Webauthn : inclut la bibliothèque javascript utilisée par défaut. Vous pouvez désactiver cette propriété et utiliser votre propre bibliothèque webauthn.
• Test : désactivé par défaut, utilisez uniquement pour tester la fonctionnalité WebAuthn.

 

Exemple : si votre serveur écoute sur le domaine www.test.com, la requête vers les options d'authentification sera par défaut http://www.test.com/sgcWebAuthn/Authentication/Options

 

Options WebAuthn

Dans cette propriété, vous pouvez configurer les options principales du composant serveur WebAuthn.

 

• RelyingParty : propriété obligatoire dans laquelle le nom DNS du serveur doit être défini. Exemple : si le serveur fonctionne sur le domaine www.test.com, définissez cette propriété sur « www.test.com ».

 

WebAuthn utilise les origines pour appliquer les contraintes de politique same-origin, essentielles pour prévenir le phishing et les attaques cross-site. Lors des processus d'enregistrement et d'authentification WebAuthn, l'origine est strictement validée par le navigateur et l'authentificateur.

 

• Origins : Si les requêtes peuvent provenir de différentes origines, utilisez la propriété Origin pour définir les origines supplémentaires. Exemple : si les requêtes peuvent provenir de login.test.com et www.test.co.uk, configurez la propriété Origins avec les valeurs : https://login.test.com et https://www.test.co.uk

 

• TopOrigins : Normalement, WebAuthn se base sur l'origine du cadre appelant (c'est-à-dire celui qui appelle navigator.credentials.create() ou navigator.credentials.get()). Cependant, des pages web peuvent être intégrées dans des iframes, qui peuvent provenir d'une origine différente de la page de niveau supérieur. Cela ouvre la possibilité d'abus ou d'attaques de type clickjacking. Pour atténuer cela, la spécification WebAuthn Level 2 introduit TopOrigin où vous pouvez définir les TopOrigins.

 

Dans WebAuthn, crossOrigin est un paramètre booléen qui indique si l'opération WebAuthn est effectuée depuis un contexte d'origine croisée, par exemple une iframe intégrée depuis une origine différente du contexte de navigation de niveau supérieur.

Ce paramètre a été introduit pour aider les navigateurs et les authentificateurs à gérer en toute sécurité les demandes d'authentification dans les environnements intégrés — un scénario courant dans les applications web modernes.

 

• AllowCrossOrigins : si true, indique que les requêtes effectuées depuis un iframe cross-origin (par exemple, un iframe sur https://auth.example.com intégré dans une page sur https://app.example.org) sont autorisées. Par défaut, cette option est désactivée.

 

WebAuthn prend en charge une variété d'algorithmes cryptographiques pour la génération et la vérification des identifiants de clé publique. Ces algorithmes sont utilisés lors de l'enregistrement des identifiants (avec navigator.credentials.create()) et de l'authentification (avec navigator.credentials.get()), et ils garantissent une signature et une validation sécurisées des défis à l'aide de paires de clés asymétriques. Le serveur est configuré par défaut avec ES256 et RS256 qui sont les algorithmes les plus courants. Vous pouvez modifier à tout moment les algorithmes pris en charge depuis la propriété Algorithms. Les algorithmes suivants sont pris en charge :

 

• ES256
• ES384
• ES512
• RS256
• RS384
• RS512
• PS256
• PS384
• PS512
• RS1
• EdDSA

 

Dans WebAuthn, l'attestation est un mécanisme optionnel qui permet à l'authentificateur (ex : appareil ou clé de sécurité) de fournir des informations sur son fabricant, son modèle et ses caractéristiques de sécurité lors de la création d'une credential. Ces informations aident la Partie de confiance (RP) à décider si elle doit faire confiance à l'authentificateur.

 

Différents formats d'attestation définissent la façon dont ces données sont structurées et vérifiées. Trois formats couramment utilisés sont android-key, packed, et d'autres comme fido-u2f, apple ou none. Par défaut, tous les formats d'attestation sont activés. Vous pouvez trouver ci-dessous la liste des formats d'attestation pris en charge :

 

• NoneAttestation : dans ce cas, aucune donnée d'attestation n'est retournée. Priorité à la confidentialité de l'utilisateur en évitant l'exposition des identifiants d'appareil. Fréquent dans les applications qui ne se soucient pas de la provenance de l'appareil.

 

• PackedAttestation : est un format flexible et compact utilisé par de nombreux authentificateurs. L'authentificateur renvoie un certificat d'attestation et une signature. Peut être : Attestation complète : signée avec une clé et un certificat fournis par le fabricant ou Auto-attestation : signée à l'aide de la clé privée de l'identifiant. Le plus largement utilisé sur différentes plateformes (p. ex., YubiKey, Windows Hello).

 

• TPMAttestation : Utilisé par les appareils équipés d'un module de plateforme de confiance (TPM). L'attestation est signée à l'aide de clés du TPM et inclut une chaîne de certificats. Utilisé par les postes de travail et ordinateurs portables d'entreprise avec puces TPM (ex. machines Windows).

 

• AndroidKeyAttestation : Utilisé par les appareils Android avec le Keystore Android. La clé est générée dans le matériel, et l'attestation inclut des informations signées par une chaîne de certificats émise par le fabricant de l'appareil. Utilisé par les téléphones Android avec des keystores matériels (TEE ou StrongBox).

 

• AppleAttestation : Utilisé par les authentificateurs de plateforme Apple, tels que Touch ID et Face ID. L'attestation est générée par les API internes d'Apple et inclut un format de certificat spécial. Utilisé sur Safari avec la biométrie Apple.

 

• FidoU2FAttestation : Format d'attestation hérité utilisé par les authentificateurs FIDO U2F. Retourne un certificat et une signature compatibles U2F. Utilisé par les anciennes clés de sécurité (ex. : les premiers YubiKeys) qui supportent FIDO U2F.

 

Dans l'API WebAuthn, AllowCredentials est un champ optionnel utilisé lors du processus d'authentification (via navigator.credentials.get()). Il spécifie une liste d'identifiants de credential autorisés à authentifier l'utilisateur pour un Relying Party (RP) particulier. Ce mécanisme permet au RP de contrôler quels credentials sont considérés comme valides pour une tentative de connexion. La propriété credentials comporte les champs suivants :

 

• AllowCredentials : si activé (false par défaut), spécifie une liste d'identifiants de credential autorisés à authentifier l'utilisateur

 

• ExcludeCredentials : pour un nom d'utilisateur donné, affiche toutes les informations d'identification existantes déjà stockées dans le composant serveur.

 

• Limit : le nombre maximum d'identifiants qui seront envoyés lorsque ExcludeCredentials est true.

 

Protocole WebAuthn

 

• Enregistrement WebAuthn : Le serveur génère un défi et l'envoie au client, qui utilise un authentificateur (par exemple une clé de sécurité ou un appareil biométrique) pour créer une paire de clés. La clé publique est renvoyée et stockée par le serveur pour l'authentification future. Retrouvez ci-dessous plus d'informations sur les événements du flux d'enregistrement :
  • Demande d'enregistrement WebAuthn
  • Réponse d'enregistrement WebAuthn
  • Résultat d'enregistrement WebAuthn

 

• Authentification WebAuthn : Le serveur envoie un défi au client, qui le signe en utilisant la clé privée précédemment enregistrée stockée dans l'authentificateur. La réponse signée est vérifiée par le serveur en utilisant la clé publique stockée pour confirmer l'identité de l'utilisateur. Retrouvez ci-dessous plus d'informations sur les événements du flux d'authentification :
  • Demande d'authentification WebAuthn
  • Réponse d'authentification WebAuthn
  • Résultat d'authentification WebAuthn

 

• MDS : Le service de métadonnées FIDO Alliance (MDS) est un référentiel centralisé de déclarations de métadonnées utilisé par les parties de confiance pour valider l'attestation des authentificateurs et prouver l'authenticité du modèle d'appareil.

 

 

• Autorisation : Le client peut demander un jeton Bearer au serveur lors du flux d'authentification. Ce jeton peut être utilisé ultérieurement pour ouvrir une nouvelle connexion WebSocket ou HTTP sans avoir besoin de se connecter avec des passkeys.
  • Autorisation WebSocket WebAuthn
  • Autorisation HTTP WebAuthn