API de vérification d'identité : Guide d'intégration et d'évaluation (FR)

Une API de vérification d'identité permet à une application de collecter ou de soumettre des preuves d'identité et de recevoir des résultats structurés concernant une personne déclarée. Selon le flux de travail, elle peut valider un document d'identité, extraire des attributs, comparer un demandeur en direct à un portrait de référence, vérifier la vivacité, corroborer des données ou orchestrer plusieurs vérifications en une seule session.

La réponse de l'API est une preuve, pas une décision commerciale complète. Une intégration en production doit également définir la capture de confiance, la propriété de l'état du client, les transitions de statut, les tentatives, l'examen, la confidentialité, la tenue des registres et la politique qui transforme les résultats techniques en approbation, nouvelle tentative, renforcement, examen ou refus.

Points clés à retenir

• Une API de vérification d'identité est plus qu'un simple point de terminaison. Le contrat réel inclut la capture, les états asynchrones, les preuves, les événements, la réconciliation, l'examen et la suppression.
• Le backend est responsable de la décision. Une redirection client ou un écran de succès visuel n'est pas autoritaire ; l'état final doit être confirmé côté serveur.
• Les résultats nécessitent une portée et des raisons. L'authenticité du document, le lien avec le titulaire, la vivacité, la qualité et le risque contextuel doivent rester séparables plutôt que de se fondre dans un booléen inexpliqué.
• La fiabilité apparaît dans les chemins d'échec. L'idempotence, la vérification des webhooks, la relecture des événements, les délais d'attente, les tentatives, le versionnement et la parité du bac à sable sont aussi importants que le chemin nominal.
• L'évaluation doit utiliser des populations similaires à celles de la production. La couverture, la résistance à la fraude, l'achèvement, les faux résultats, la charge d'examen et la confidentialité doivent être mesurés par document, appareil, géographie et segment d'utilisateur pertinent.

Que fait une API de vérification d'identité ?

Une API de vérification d'identité fournit une interface lisible par machine pour les capacités de vérification d'identité. Une intégration typique crée une tentative de vérification, dirige le demandeur à travers une expérience de capture sécurisée, reçoit des événements de progression ou d'achèvement, récupère la preuve finale et applique la politique de l'organisation utilisatrice.

Le modèle de vérification d'identité NIST SP 800-63A-4 sépare trois fonctions importantes :

• Résolution : distinguer la personne déclarée au sein de la population pertinente.
• Validation : déterminer si les preuves d'identité et les attributs sont authentiques, précis et acceptables.
• Vérification : établir que le demandeur est le sujet associé à cette preuve.

Une API peut effectuer une, deux ou les trois fonctions. Les noms de produits ne garantissent pas la portée, les exigences doivent donc indiquer la conclusion exacte attendue de chaque résultat.

API de vérification d'identité, API de document, API KYC et OCR comparées

Interface	Objectif principal	Résultat utile	Ce qu'elle ne prouve pas seule
API OCR	Convertir les pixels d'un document en texte ou champs	Nom, date, numéro, adresse extraits	Authenticité, possession ou risque client
API de vérification de document	Valider un document et ses preuves capturées	Vérifications d'authenticité, expiration, cohérence des champs, indicateurs de falsification	Que le demandeur actuel en est le propriétaire
API de correspondance faciale	Comparer un visage soumis à une référence	Décision de similarité ou de correspondance à un seuil	Vivacité, authenticité du document ou identité légale
API de vivacité	Estimer la présence en direct lors de la capture biométrique	Preuve de bonne foi, d'attaque, de nouvelle tentative ou de score	L'identité de la personne
API de vérification d'identité	Combiner la validation des preuves et le lien avec le demandeur	Résultats au niveau des preuves et résultat du flux de travail	KYC complet ou éligibilité commerciale
API KYC	Soutenir un flux de diligence raisonnable client plus large	Identité, filtrage, risque, flux de travail et enregistrements	Conformité automatique sans politique organisationnelle

Cette distinction prévient les erreurs architecturales. Par exemple, l'ajout d'OCR à un formulaire de téléchargement accélère la saisie de données mais n'authentifie pas le document. L'ajout de la correspondance faciale relie deux images, mais ne peut pas établir si l'une ou l'autre image a été obtenue par une capture fiable et en direct.

Pour le contexte plus large de la politique, du filtrage, des risques et de l'examen continu autour de ces interfaces, consultez le guide du cycle de vie KYC. Cet article reste à la limite de confiance du développeur : capture, état de l'API, preuves, événements, réconciliation et décisions backend.

Modèles d'intégration courants

Session de vérification hébergée

Le backend de l'application crée une session et reçoit une URL ou un jeton de courte durée. L'utilisateur effectue la capture dans un parcours hébergé par le fournisseur, puis retourne à l'application. Ce modèle peut réduire la complexité du frontend et de l'appareil tout en préservant le contrôle côté serveur.

Les questions clés incluent la marque, le transfert de domaine, l'accessibilité, la localisation, le support des navigateurs mobiles, l'expiration de session, le comportement de retour et la manière dont l'application reprend lorsque l'utilisateur change d'appareil.

SDK web ou mobile intégré

Un SDK exécute l'expérience de capture au sein de l'application. Il peut offrir un contrôle d'interface plus strict et un accès aux capacités de l'appareil, mais la qualité de l'intégration affecte la sécurité. Le support de version, l'intégrité de l'application, les autorisations de caméra, la gestion des caméras virtuelles, la politique de mise à jour et la télémétrie font partie de l'examen.

Vérification autonome de serveur à serveur

Le système client envoie des données structurées ou des médias directement à un point de terminaison. Ceci est utile pour les captures déjà fiables, les opérations par lot ou les modules individuels. Cela transfère également la responsabilité de l'intégrité de la capture, du consentement, de la qualité, de la sécurité de la charge utile et de la prévention des relectures vers l'intégrateur.

Flux de travail orchestré

Une session peut se ramifier entre la validation de documents, les vérifications de bases de données, la vivacité, la correspondance faciale, le filtrage, les signaux d'appareil et l'examen manuel. L'API doit exposer la version du flux de travail et de la politique afin que le même statut puisse être interprété ultérieurement.

Une séquence d'intégration sécurisée

1. Créer la tentative depuis le backend

Le backend de confiance génère une référence client interne et appelle le fournisseur avec le flux de travail, la locale et le contexte de politique requis. N'exposez pas les informations d'identification d'API permanentes dans le code du navigateur ou mobile.

Utilisez une stratégie d'idempotence pour les opérations de création. Un délai d'attente client ne doit pas créer une deuxième tentative facturable ou détacher le résultat du client d'origine.

2. Émettre un transfert de capture de courte durée

Donnez au frontend uniquement le jeton ou l'URL délimité nécessaire pour cette tentative. Liez-le à l'application attendue, à la référence client, au flux de travail et à l'expiration. Évitez de placer des données personnelles inutiles dans les URL, les événements analytiques ou les journaux clients.

3. Capturer et valider les preuves

Guidez l'utilisateur à travers les preuves prises en charge et les exigences de qualité. Séparez les problèmes de qualité récupérables des attaques suspectées. « Rapprochez-vous », « document expiré » et « intégrité de la capture échouée » ne devraient pas devenir une erreur générique.

4. Recevoir un événement authentifié

Traitez les webhooks comme une entrée non fiable jusqu'à vérification. Validez la signature de l'événement ou l'authentification du message, l'horodatage ou le contrôle de fraîcheur, la destination attendue, le type de contenu et l'identifiant de l'événement. RFC 9421 définit un mécanisme général pour les signatures de messages HTTP, bien qu'un fournisseur puisse utiliser un schéma de signature documenté différent.

Stockez les identifiants d'événements et traitez-les de manière idempotente. Les systèmes de livraison réessayent ; les événements en double sont normaux. Ne supposez pas l'ordre d'arrivée et ne laissez pas un événement plus ancien faire reculer un client d'un état terminal.

5. Récupérer le résultat canonique

Après un événement d'achèvement, récupérez la tentative finale de l'API du fournisseur. Cette étape de réconciliation réduit la dépendance au contenu d'un seul webhook et permet de récupérer les livraisons manquées ou retardées.

6. Appliquer la politique de l'organisation

Mappez les preuves structurées aux propres états de décision de l'organisation. Le fournisseur peut recommander un résultat, mais l'organisation utilisatrice connaît le produit, l'historique du client, la base légale, l'appétit pour le risque et les chemins de récupération disponibles.

7. Enregistrer la transition

Conservez la référence client interne, l'identifiant de tentative du fournisseur, le flux de travail et sa version, les preuves ou références pertinentes, les codes de motif, l'historique des événements, la version de la politique, l'action du réviseur et la justification finale. Minimisez les données sensibles copiées lorsqu'une référence durable est suffisante.

Le modèle d'état qu'une API devrait exposer

Un champ booléen verified est trop petit pour un véritable parcours client. Les états utiles incluent souvent :

État	Signification	Action d'application typique
Créé	La tentative existe mais la capture n'a pas commencé	Présenter ou renvoyer le transfert sécurisé
En cours	L'utilisateur ou les vérifications asynchrones sont actives	Attendre ; ne pas accorder l'accès final
En attente de saisie	Plus de preuves ou une action de l'utilisateur sont nécessaires	Afficher des conseils de récupération précis
Nouvelle tentative autorisée	La capture ou la qualité a échoué de manière récupérable	Lancer une nouvelle tentative limitée
En cours d'examen	Un réviseur qualifié est en charge du cas	Maintenir l'accès en suspens et exposer la prochaine étape attendue
Approuvé	Les preuves requises ont satisfait le flux de travail configuré	Appliquer la politique de l'organisation et la transition d'état
Refusé	Les preuves n'ont pas satisfait un contrôle défini	Appliquer l'appel, la restriction ou le chemin alternatif
Expiré ou abandonné	La tentative s'est terminée sans décision	Permettre un redémarrage contrôlé
Erreur technique	Le système n'a pas pu produire de preuves	Réessayer ou réconcilier sans le traiter comme une fraude

Chaque statut terminal doit avoir des raisons structurées. Les codes machine stables permettent la politique et l'analyse ; les messages humains localisés aident les utilisateurs et les réviseurs. RFC 9457 fournit un format standard pour les détails de problème HTTP lisibles par machine au niveau de l'interface.

Quelles preuves le résultat doit-il contenir ?

Preuves au niveau du document

Incluez le type de preuve, le pays émetteur, la classe de document, l'expiration, la cohérence des champs, la qualité et les indicateurs de validation pertinents pour la méthode. Indiquez clairement si le résultat provient d'une inspection optique, de données de puce, d'une corroboration de l'émetteur ou de la base de données, ou d'une autre source.

Preuves de lien avec le demandeur

Gardez séparés la comparaison faciale, la vivacité, l'intégrité de la capture et le lien des attributs d'identité. Enregistrez la référence utilisée et le seuil de décision ou la version nécessaire pour une interprétation ultérieure sans exposer de matériel biométrique inutile à chaque consommateur.

Preuves de risque et opérationnelles

Les signaux d'appareil, d'IP, de vélocité, de tentatives répétées ou de flux de travail peuvent guider le renforcement et l'examen. Ils ne devraient pas modifier silencieusement les attributs d'identité. Préservez quel sous-système a produit chaque raison.

Provenance et version

Les résultats peuvent changer lorsque les modèles, les modèles de documents, les listes de surveillance ou la politique changent. Stockez la version du fournisseur, la version du flux de travail, l'heure de la décision, les références sources et si un humain a examiné le cas.

Exigences de sécurité des API

Les API d'identité traitent des données personnelles et biométriques précieuses et exposent des flux commerciaux que les attaquants peuvent automatiser. Le Top 10 de la sécurité des API OWASP met en évidence les risques directement pertinents ici : autorisation d'objet défectueuse, authentification défectueuse, exposition excessive de propriétés, consommation de ressources illimitée, automatisation de flux sensibles, mauvaise gestion de l'inventaire API et confiance dangereuse dans les API tierces.

Authentification et autorisation

Utilisez des informations d'identification et des applications distinctes pour les tests et la production. Appliquez le principe du moindre privilège, la rotation, la révocation, l'isolation de l'environnement et l'autorisation au niveau de l'objet. Une organisation authentifiée ne devrait pas pouvoir récupérer la tentative d'une autre organisation en modifiant un identifiant.

Contrôles de téléchargement et de ressources

Validez le type de média, la taille, les dimensions, la structure et la source attendue. Définissez des délais d'attente, des limites de concurrence, des contrôles de débit et des limites de tentatives. Les appels de vérification consomment des ressources de calcul et peuvent entraîner un coût par vérification, ce qui rend les points de terminaison illimités à la fois un risque de déni de service et un risque de coût.

Exposition des données

Ne renvoyez que les champs dont un consommateur a besoin. Séparez les rôles opérationnels afin que le support, les analystes, les développeurs et les administrateurs ne reçoivent pas tous par défaut des preuves d'identité complètes. Rédigez les charges utiles sensibles des journaux et des outils d'observabilité.

Contrôles de webhook et de relecture

Authentifiez les événements, conservez le corps brut requis pour la vérification de la signature, rejetez les livraisons obsolètes ou mal formées, dédupliquez les identifiants d'événements et récupérez l'état canonique. Faites pivoter les secrets de webhook sans interrompre la livraison en cours.

Inventaire et versionnement

Documentez chaque point de terminaison actif, version, hôte, identifiant, rappel, SDK et date de dépréciation. Un point de terminaison de test fantôme avec des données de production ou un ancien SDK non maintenu peut compromettre le chemin examiné.

Comment tester une API de vérification d'identité

Tests de contrat et d'état

Exercez chaque état, raison, nouvelle tentative, délai d'attente et transition terminale documentés. Vérifiez la pagination, le filtrage, les corps d'erreur, la rétrocompatibilité et le comportement des champs inconnus. Simulez des webhooks en double et désordonnés.

Tests de preuves

Utilisez des échantillons autorisés et représentatifs pour les types de documents, les pays, les scripts, les conditions d'expiration, les appareils, les caméras et les réseaux de la population attendue. Suivez séparément les preuves non prises en charge, illisibles, non concordantes, manipulées et authentiques.

Tests de fraude

Créez un ensemble d'attaques autorisées pour les relectures, les preuves imprimées, les documents altérés, les caméras virtuelles, les émulateurs, les médias injectés, les identités répétées et les tentatives automatisées. Les exigences de vérification à distance du NIST distinguent la confiance du capteur de capture, l'analyse des médias falsifiés, les canaux protégés et la comparaison biométrique, car aucun mécanisme unique ne couvre le chemin complet.

Tests opérationnels

Mesurez l'achèvement, les tentatives, l'abandon, le taux d'examen manuel, le temps de résolution, les contacts de support, le délai de webhook, la réconciliation et la disponibilité. Ventilez les résultats par document, appareil, réseau, langue et groupe de clients pertinent.

Tests de qualité de décision

Ne comparez pas les fournisseurs avec un seul chiffre « d'exactitude ». Examinez les faux positifs et les faux négatifs au seuil prévu, les résultats spécifiques aux attaques, les nombres d'échantillons, la confiance, les cas sans réponse et les résultats confirmés en aval.

Tests de confidentialité et de suppression

Vérifiez la configuration de rétention, l'exportation, la suppression, les journaux d'accès, la gestion régionale, les contrôles des sous-traitants et le comportement lorsqu'une demande de suppression arrive pendant un examen ouvert ou une conservation légalement requise.

Comment évaluer les fournisseurs

Portée et assurance

Quelles fonctions de vérification sont incluses ? Quels modèles d'assurance et tests indépendants s'appliquent ? Quels composants et versions ont été testés ? Le fournisseur peut-il expliquer ce qu'un succès signifie et ne signifie pas ?

Couverture

Demandez une matrice pays-document, pas seulement un total. Testez les preuves que vos clients présentent, y compris les appareils plus anciens, les scripts multiples, les caméras de moindre qualité et les documents légitimes mais peu courants.

Expérience développeur

Examinez la cohérence de l'API, la qualité d'OpenAPI, la maintenance du SDK, les exemples, les scénarios de bac à sable, les outils de webhook, la discipline du journal des modifications, la politique de migration, la page d'état et l'escalade du support. Un exemple de chemin nominal de cinq lignes n'est pas un guide d'intégration en production.

Opérations et explicabilité

Inspectez les files d'attente d'examen, les vues de preuves, les autorisations de rôle, les journaux d'audit, les codes de motif, les appels et les exportations. Confirmez que les humains peuvent distinguer l'échec technique, la nouvelle tentative de qualité, l'attaque probable et l'inadéquation d'identité.

Commercial et portabilité

Comprenez la facturation basée sur le succès par rapport à la facturation basée sur la tentative, les frais d'examen, les minimums, les limites, le stockage, les options régionales et les conditions de sortie. Gardez votre référence client interne et votre limite de politique portables afin qu'un changement de fournisseur ne nécessite pas de réécrire l'état du compte.

Erreurs d'intégration courantes

Accorder l'accès depuis l'URL de retour

L'utilisateur contrôle le chemin du navigateur. Une redirection de succès est un état d'interface, pas une preuve. Confirmez l'état final depuis le backend de confiance.

Traiter chaque échec comme une fraude

Le refus d'autorisation, le délai d'attente, les preuves non prises en charge, le flou et la manipulation suspectée sont différents. Les mélanger crée de faux refus et des analyses inutilisables.

Traiter les webhooks exactement une fois

Les réseaux ne peuvent pas promettre une livraison exactement une fois. Concevez pour des événements au moins une fois avec déduplication, transitions monotones et récupération canonique.

Journalisation des charges utiles complètes

La journalisation de débogage pratique peut copier des documents et des données biométriques dans des systèmes avec un accès plus large et une rétention plus longue. Utilisez des identifiants, des raisons structurées et un accès contrôlé aux preuves.

Tester uniquement le cas de succès du bac à sable

Les échecs de production se produisent lors des tentatives, sur les anciens appareils, les documents marginaux, les délais d'événements, les changements de version et l'examen. Intégrez les scénarios d'échec à la suite d'acceptation.

Externaliser la décision politique

Le résultat d'un fournisseur ne peut pas connaître chaque juridiction, type de client, risque produit ou restriction commerciale. Préservez la logique de décision et la responsabilité de l'organisation.

Une liste de contrôle d'implémentation

Avant la production, confirmez que :

• les informations d'identification de l'API restent côté serveur et sont délimitées par l'environnement et le rôle ;
• les appels de création sont idempotents et mappés à des références client internes stables ;
• les jetons de capture sont de courte durée et liés à la tentative attendue ;
• chaque état et raison a une action client et backend explicite ;
• les signatures de webhook, la fraîcheur, les doublons et l'ordre sont testés ;
• la récupération canonique réconcilie les événements manqués ou retardés ;
• les sorties au niveau des preuves restent séparées de la décision client finale ;
• les contrôles de débit, de téléchargement, de concurrence et de tentative résistent aux abus automatisés ;
• les tests de document, d'appareil, de fraude, de confidentialité, d'accessibilité et d'examen utilisent des échantillons similaires à ceux de la production ;
• la rétention, la suppression, la réponse aux incidents, le versionnement et la migration ont des propriétaires.

Utiliser Didit pour la vérification d'identité

Didit fournit la vérification d'identité en tant que module composable et permet aux équipes d'ajouter la détection de vivacité, l'analyse d'appareil et d'IP, et des chemins conditionnels via l'orchestrateur de flux de travail. Le prix public de la vérification d'identité autonome est de 0,15 $, tandis que le bundle KYC publié à 0,33 $ combine la vérification d'identité, la vivacité passive, la correspondance faciale et l'analyse d'IP.

La page de tarification liste les tarifs actuels des modules, et le niveau gratuit inclut 500 vérifications gratuites par mois. Ces résultats de produits devraient alimenter une politique et un état client gérés par le backend plutôt que de les remplacer.

Questions fréquemment posées

Qu'est-ce qu'une API de vérification d'identité ?

C'est une interface programmable pour collecter ou soumettre des preuves d'identité et recevoir des résultats structurés sur la validité des preuves et le lien du demandeur à une identité déclarée.

Une API de vérification d'identité est-elle la même qu'une API KYC ?

Pas nécessairement. La vérification d'identité se concentre sur les preuves d'identité et le lien avec le titulaire. Une API KYC peut également inclure le filtrage, le risque client, les flux de travail, l'examen, les enregistrements et l'actualisation continue.

La vérification d'identité doit-elle s'exécuter depuis le frontend ?

L'interface de capture peut s'exécuter dans le frontend, mais les informations d'identification permanentes, la création de session, la récupération du résultat final, les décisions politiques et les changements d'état client appartiennent à un backend de confiance.

Pourquoi les webhooks sont-ils nécessaires ?

De nombreuses vérifications et examens sont asynchrones. Les webhooks notifient l'application des changements, tandis qu'un point de terminaison de récupération fournit l'état canonique pour la réconciliation.

Comment gérer les webhooks en double ?

Vérifiez chaque événement, stockez son identifiant, traitez-le de manière idempotente, empêchez les états plus anciens d'écraser les états terminaux plus récents et récupérez la tentative canonique si nécessaire.

Que doit inclure un bac à sable ?

Il doit reproduire le contrat de production et fournir des cas déterministes pour le succès, la nouvelle tentative, le refus, l'examen, l'expiration, l'erreur technique, les événements en double, les événements retardés et les codes de motif pertinents.

Une API peut-elle rendre une entreprise conforme ?

Non. Une API peut fournir des preuves et des résultats de flux de travail. L'organisation reste responsable de l'analyse juridique, de la politique, des décisions client, des exceptions, des enregistrements, de la confidentialité et des contrôles continus.

Références primaires

• NIST SP 800-63A-4: Preuve d'identité et enrôlement
• Top 10 de la sécurité des API OWASP — 2023
• RFC 9110: Sémantique HTTP
• RFC 9421: Signatures de messages HTTP
• RFC 9457: Détails des problèmes pour les API HTTP

Une intégration robuste de la vérification d'identité rend chaque limite de confiance explicite : qui crée la tentative, comment les preuves sont capturées, quel résultat est canonique, comment les événements sont authentifiés, ce que chaque raison signifie et quel système est responsable de la décision client finale.