Authentification biométrique renforcée pour l'accès aux API d'IA : Lier le privilège à une personne (FR)

La vérification à l'intégration prouve qui a créé un compte. Elle ne prouve rien sur qui l'utilise actuellement.

Cet écart est courant dans la plupart des produits et a des conséquences importantes sur une plateforme d'IA, où les actifs derrière le compte sont l'accès au modèle, les crédits et les quotas. Une clé API est un jeton porteur — quiconque la détient est le compte. Les clés sont partagées au sein des équipes, collées dans des dépôts, vendues et prises en charge. Six mois après une intégration réussie, « ce compte a été vérifié » est une déclaration sur le passé.

L'authentification biométrique comble cet écart. Elle revérifie l'humain réel au moment d'une action privilégiée — sans documents, sans mot de passe, en moins de deux secondes, 0,10 $ par authentification.

Points clés à retenir

• La vérification à l'intégration est un instantané. L'authentification biométrique est un contrôle au moment où cela compte.
• Détection de vivacité plus correspondance faciale avec le portrait déjà stocké lors de la vérification originale de l'utilisateur. Aucun document, aucun mot de passe.
• Session uniquement. Il n'y a pas de point de terminaison /v3/biometric-auth/ — cela se fait via une session avec workflow_type=BIOMETRIC_AUTHENTICATION.
• Le détail d'implémentation critique : utilisez le même vendor_data que la vérification originale de l'utilisateur, sinon le visage stocké ne peut pas être récupéré.
• Bons déclencheurs : augmentations de quota, octrois de crédit, émission de nouvelles clés API, mises à niveau de niveau, ajout de membres d'équipe privilégiés, et toute alerte comportementale de votre couche de trafic.
• 0,10 $ par authentification, paiement à la réussite, moins de deux secondes.

Pourquoi la réauthentification est essentielle sur une plateforme d'IA

Trois modes de défaillance rendent l'instantané d'intégration insuffisant.

Partage et revente de clés. Une clé délivrée à un développeur vérifié peut se retrouver n'importe où. Le compte reste vérifié; la personne qui l'utilise n'est pas la personne qui a été vérifiée. C'est le mécanisme par lequel un compte légitimement vérifié devient un point d'entrée dans un réseau frauduleux — et il est invisible pour tout contrôle qui ne se penche que sur l'intégration.

Prise de contrôle de compte. Les identifiants sont hameçonnés ou devinés, et l'attaquant hérite d'un compte vérifié avec une réputation établie et des limites élevées. Un compte vérifié est une cible de prise de contrôle plus attrayante, pas moins.

Escalade après coup. Le compte qui a été vérifié pour un accès modeste en janvier demande une augmentation de quota de 50 fois en août. Rien dans la vérification de janvier ne concerne la demande d'août.

Dans les trois cas, le statut de vérification du compte est inchangé et l'humain derrière n'est pas celui que vous pensez. Un mot de passe, un code à usage unique ou un jeton de session ne peuvent pas distinguer ces cas, car chacun d'eux est un attaquant qui détient légitimement l'identifiant. Seul un contrôle biométrique pose la question qui compte : la personne présente est-elle celle qui a été vérifiée ?

Comment ça marche

L'authentification biométrique réutilise les mêmes composants LivenessV3 et FaceMatchV3 que le flux d'identité régulier. La seule différence est la provenance de l'image de référence — au lieu du portrait sur un document fraîchement soumis, elle utilise le portrait déjà stocké de la vérification précédente de l'utilisateur.

C'est pourquoi elle n'a pas besoin de documents, et pourquoi elle est suffisamment rapide et bon marché pour s'intégrer dans un flux de produit normal.

C'est une session uniquement

Il n'y a pas de point de terminaison dédié /v3/biometric-auth/. L'authentification est délivrée via une session dont le workflow est configuré pour cela — workflow_type=BIOMETRIC_AUTHENTICATION. Si vous cherchez un point de terminaison autonome dans la référence API, c'est pourquoi vous ne pouvez pas en trouver.

Le flux

1. Configurez un workflow de type BIOMETRIC_AUTHENTICATION dans la console et notez son workflow_id.
2. Créez une session :

curl -X POST 'https://verification.didit.me/v3/session/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "workflow_id": "YOUR_BIOMETRIC_AUTH_WORKFLOW_ID",
    "vendor_data": "acct_8842",
    "callback": "https://yourplatform.example/auth/complete"
  }'

1. Envoyez l'utilisateur via la session renvoyée — hébergée ou intégrée avec l'un des SDK gratuits.
2. Récupérez la décision :

curl -X GET 'https://verification.didit.me/v3/session/{sessionId}/decision/' \
  -H 'x-api-key: YOUR_API_KEY'

Ou abonnez-vous à session.status.updated et utilisez le webhook.

Le seul détail qui brise les intégrations

Utilisez le même vendor_data que la vérification originale de l'utilisateur.

Cette valeur est la façon dont Didit récupère le portrait stocké pour la correspondance. Un vendor_data nouveau ou différent signifie qu'il n'y a pas de visage stocké à comparer, et le flux ne peut pas faire ce que vous avez demandé. Si vous devez délibérément remplacer la référence stockée, passez portrait_image explicitement — mais le chemin normal est un vendor_data stable par compte, défini à l'intégration et réutilisé pour toujours.

C'est l'argument pour traiter vendor_data comme un identifiant de première classe dans votre propre schéma dès le premier jour. C'est aussi ce qui permet aux résultats de la recherche faciale de correspondre proprement à vos comptes.

Lecture du résultat

Les résultats arrivent dans liveness_checks et face_matches. Les deux sont toujours des tableaux — jamais des objets singuliers — et chaque élément contient un node_id afin que les workflows multi-instances puissent lever l'ambiguïté des étapes. Chacun est null tant que son étape n'a pas produit de données.

Les avertissements incluent LOW_LIVENESS_SCORE, les alertes d'attaque faciale, les correspondances de liste noire et une faible similarité de correspondance faciale. Les seuils et les actions de refus sont configurables, vous pouvez donc appliquer une barre plus stricte pour un octroi de crédit important que pour une augmentation de quota de routine.

Ce qui devrait déclencher une élévation

La valeur de ce contrôle dépend presque entièrement de la conception du déclencheur. Trop nombreux et vous avez créé un désagrément ; trop peu et il ne se déclenche jamais quand cela compte.

Escalade d'accès — augmentations de quota, octrois de crédit, émission de nouvelles clés API, mises à niveau de niveau, passage à un niveau de capacité que vous considérez comme sensible.

Modifications de compte — un nouveau membre d'équipe privilégié, un changement de propriétaire de facturation, un changement de destination de paiement, une réinitialisation de mot de passe ou de MFA.

Alertes comportementales — le déclencheur le plus précieux. Lorsque votre propre couche de trafic signale un compte pour des requêtes concentrées ou un modèle de distillation, une élévation biométrique pose la seule question que la couche de trafic ne peut pas : l'humain vérifié est-il toujours celui qui opère ce compte ? Un succès affine l'interprétation. Un échec ou un abandon est lui-même un signal fort.

Signaux de liaison — une session portant DEVICE_RECOVERED_HIGH_CONFIDENCE, ou un visage qui correspondait à un utilisateur vérifié existant, a justifié une élévation, quelle que soit la demande du compte.

Inactivité plus escalade — un compte silencieux pendant des mois qui demande soudainement une forte augmentation. Pas l'inactivité seule ; la combinaison.

Pourquoi ne pas simplement exiger un mot de passe ou un code ?

Parce que chaque facteur conventionnel est un identifiant porteur, et le modèle de menace ici est un attaquant qui détient l'identifiant.

Un code à usage unique est envoyé au numéro de téléphone ou à l'adresse enregistrée — que l'attaquant contrôle après une prise de contrôle, et que le partageur de clé légitime transfère simplement. Un mot de passe prouve la connaissance d'une chaîne. Une clé matérielle prouve la possession d'un objet, qui peut être remis avec la clé.

Une correspondance faciale vérifiée par la détection de vivacité prouve qu'un être humain spécifique est présent à ce moment. Pour lier un privilège à une personne, c'est le seul facteur qui répond à la question réelle. À 0,10 $ et en moins de deux secondes, c'est aussi assez bon marché pour être utilisé sur de vrais déclencheurs plutôt que de le garder pour les urgences.

Ce qu'il ne fait pas mérite également d'être mentionné. La réauthentification de l'humain derrière un compte n'empêche pas l'extraction de modèle et ne la détecte pas. Un développeur vérifié peut toujours abuser de l'accès qu'il détient. Cela comble l'écart entre « ce compte a été vérifié une fois » et « cet humain est là maintenant » — un écart étroit et réel. Les contrôles de sortie au niveau du modèle et la détection sémantique du trafic restent des couches distinctes, et elles vous appartiennent.

Cas d'utilisation

Plateformes API d'IA régulant l'escalade de quota, les octrois de crédit et l'émission de clés derrière un contrôle sur l'humain.

Produits d'agent et d'automatisation nécessitant une élévation avant qu'un agent ne se voie accorder une nouvelle capacité ou qu'une limite de dépenses ne soit augmentée.

Services financiers se réauthentifiant avant un transfert de grande valeur ou un changement de destination de paiement.

Places de marché revérifiant un vendeur avant un changement de méthode de paiement — le gain le plus courant en cas de prise de contrôle de compte.

Toute plateforme avec un flux de récupération utilisant la réauthentification biométrique au lieu de questions basées sur la connaissance, qui sont le maillon le plus faible dans la plupart des conceptions de sécurité de compte.

Foire aux questions

L'utilisateur doit-il soumettre à nouveau un document ?

Non. C'est le but. Le contrôle est effectué par rapport au portrait déjà stocké lors de leur vérification originale — détection de vivacité plus correspondance faciale, aucun document.

Que se passe-t-il si l'utilisateur n'a jamais été vérifié avec Didit ?

Alors il n'y a pas de portrait stocké et il n'y a rien à authentifier. L'authentification biométrique est une primitive de revérification ; elle présume une vérification antérieure sous le même vendor_data.

Combien de temps cela prend-il ?

Inférence en moins de deux secondes. Du point de vue de l'utilisateur, c'est un selfie et un instant.

Peut-il fonctionner dans notre propre interface ?

Oui. Les SDK web, iOS, Android, React Native et Flutter sont tous gratuits, et White Label (0,20 $) supprime la marque Didit.

Que se passe-t-il si quelqu'un présente une photo ou une vidéo du titulaire du compte ?

C'est à cela que sert la détection de vivacité. La détection de vivacité passive de Didit détient une évaluation de détection d'attaque de présentation iBeta Niveau 1, et les alertes d'attaque faciale apparaissent dans les avertissements. Les seuils sont configurables.

Combien cela coûte-t-il ?

0,10 $ par authentification, paiement à la réussite, sans minimum.

Chaque connexion doit-elle exiger cela ?

Non. La connexion est le mauvais déclencheur — elle se déclenche constamment et la plupart du temps pour rien. Attachez-la à l'escalade de privilège et aux alertes, où le coût de l'erreur est élevé et la fréquence faible.

Prêt à commencer ?

Configurez un workflow, connectez-le à vos points d'escalade et réutilisez-le partout.

• Lisez la documentation — Vue d'ensemble de l'authentification biométrique et l'API Sessions.
• Découvrez le produit — Vérification d'utilisateur.
• Consultez les tarifs — 0,10 $ par authentification, paiement à la réussite, sans minimums.
• Commencez gratuitement — business.didit.me, 500 vérifications KYC par mois sans frais.