Passer au contenu principal
Le SDK Liveness Web de Youverify ajoute la détection de vivacité anti-deepfake à votre application web, sans redirection vers une page hébergée. L’utilisateur réalise une ou plusieurs courtes tâches, comme tracer un cercle avec la tête, et le SDK renvoie le résultat à vos callbacks.

Installation

Étapes d’intégration

1

Générer un identifiant de session et un jeton de session sur votre backend

Le SDK ne génère pas lui-même les jetons de session. Votre backend appelle l’API Youverify avec votre clé API secrète et transmet les deux valeurs à la page. Consultez Générer l’identifiant de session et le jeton de session.
2

Importer et initialiser le SDK

Pour connaître les options valides, consultez Options.
3

Démarrer le contrôle de vivacité

Vous pouvez aussi transmettre un tableau de tâches. Les tâches passées à start() remplacent celles définies lors de l’initialisation.

Générer l’identifiant de session et le jeton de session

Les deux appels doivent provenir de votre backend. Utilisez l’URL de base de l’environnement sur lequel vous testez.
N’exposez jamais votre clé API dans le code frontend. Effectuez ces appels depuis votre backend sécurisé.

Identifiant de session

POST /v2/api/identity/sdk/session/generate
En-têtes
Corps de la requête
Réponse
Transmettez le sessionId au constructeur du SDK.

Jeton de session

POST /v2/api/identity/sdk/liveness/token
En-têtes
Corps de la requête
Réponse
Transmettez l’authToken au constructeur du SDK sous le nom sessionToken. Le deviceCorrelationId doit être un identifiant unique de l’appareil ou de la session de l’utilisateur. Il aide à détecter et à prévenir les abus.

Exemple complet

Préchargement

Le SDK télécharge son modèle de détection de visage, de plusieurs Mo, avant de pouvoir lancer le contrôle de vivacité. Le téléchargement ne dépend pas de la session : lancez-le le plus tôt possible, avant de générer le sessionId et le sessionToken.
  • Vous pouvez l’appeler plusieurs fois sans risque. Les appels suivants, y compris celui du constructeur, réutilisent le téléchargement déjà en cours.
  • Si vous ne l’appelez pas, le téléchargement démarre à la construction du SDK.
  • preload() conserve le détecteur en mémoire : il n’est donc réutilisé pour le contrôle de vivacité que si la page n’est pas rechargée entre-temps. C’est le cas dans les applications monopages qui naviguent avec leur routeur.

Applications monopages

Appelez preload() dans le module d’entrée de votre application.
Un rechargement annule tout téléchargement en cours. Les fichiers déjà téléchargés proviennent du cache HTTP du navigateur, et ceux qui ont été interrompus sont retéléchargés dès l’exécution du module d’entrée.

Sites multipages

Si les utilisateurs accèdent au contrôle de vivacité par des chargements de page complets, le détecteur préchargé est supprimé à chaque navigation. Appelez plutôt prefetch() sur les pages qui précèdent le contrôle de vivacité.
Il demande au navigateur de télécharger les fichiers du détecteur dans son cache HTTP en arrière-plan, sans construire le détecteur. Lorsque le SDK démarre sur la page de vivacité, les fichiers proviennent du cache. Le détecteur est tout de même configuré sur cette page : cela économise le temps de téléchargement, mais pas le temps de configuration.
  • Vous pouvez l’appeler sur chaque page sans risque. Les fichiers déjà demandés ne sont pas ajoutés de nouveau.
  • Il repose sur le cache HTTP du navigateur. Il n’a aucun effet si le cache est désactivé, par exemple dans une webview configurée avec LOAD_NO_CACHE.
  • <link rel="prefetch"> est pris en charge par les navigateurs basés sur Chromium et par Firefox, mais pas par Safari, où prefetch() ne fait rien.

Options

string
requis
Identifiant généré par votre backend avec votre clé API. Le SDK le valide avant l’initialisation et le joint aux soumissions.
string
requis
Jeton généré par votre backend pour la vérification de vivacité.
string
Votre clé marchand publique Youverify.
boolean
défaut:"true"
Indique si la session s’exécute en mode sandbox ou en production. Définissez-la sur false en production.
string
défaut:"modal"
Mode d’affichage de l’interface. modal ou page.
array
Les tâches que l’utilisateur doit réaliser pour confirmer sa vivacité. Consultez Tâches.
string
Identifiant d’entité facultatif à inclure lors de la soumission du résultat de vivacité.
boolean
défaut:"false"
Indique s’il faut narrer des informations à l’utilisateur pendant les tâches.
object
Informations sur l’utilisateur vérifié.
object
Personnalise l’interface à l’image de votre marque.
function
Appelé lorsque la fenêtre modale est fermée.
function
Appelé lorsque toutes les tâches ont été réalisées et réussies. Reçoit les données du callback.
function
Appelé lorsqu’au moins une tâche échoue. Reçoit les données du callback.

Tâches

Une tâche est une série d’instructions que l’utilisateur suit pour confirmer sa vivacité. Transmettez les tâches dans l’option tasks ou à start(). Chaque tâche accepte ces options :

Complete the Circle

L’utilisateur complète un cercle imaginaire avec un mouvement de la tête. Utilisez id: "complete-the-circle".

Yes or No

L’utilisateur répond aux questions que vous définissez en inclinant la tête : à droite pour oui, à gauche pour non. Utilisez id: "yes-or-no".

Motions

L’utilisateur effectue des mouvements aléatoires dans un ordre aléatoire : hochements de tête, clignements des yeux et ouverture de la bouche. Utilisez id: "motions". L’utilisateur cligne des yeux un nombre de fois défini. Utilisez id: "blink".

Données du callback

onSuccess et onFailure reçoivent un objet avec les propriétés suivantes.
boolean
Indique si le contrôle de vivacité a réussi.
string
Image du visage de l’utilisateur pendant le contrôle.
string
Vidéo de l’utilisateur pendant le contrôle.
any
Métadonnées transmises lors de l’initialisation.
object
Présent uniquement en cas d’échec. Contient key (eyes_closed, image_capture_failed ou API_ERROR) et message.
Lorsque le SDK soumet la charge utile de vivacité, il inclut sdkVersion (la version du package du SDK, 1.2.3) et, si vous l’avez transmis lors de l’initialisation, entityId.

Erreurs et nouvelles tentatives

  • Si la validation de la session échoue, générez un nouveau sessionId et réessayez.
  • Si le contrôle de vivacité échoue, l’utilisateur peut réessayer tant que le sessionId actuel reste valide.
  • Si le sessionId expire, créez une nouvelle session et recommencez le processus.
Utilisez sandboxEnvironment: true pour les tests et sandboxEnvironment: false en production.
Pour les endpoints de jeton communs à tous les SDK, consultez Jetons de session.