Autenticació Biomètrica per a l'Accés a l'API d'IA: Vinculant el Privilegi a una Persona (CA)

La verificació en l'onboarding demostra qui va crear un compte. No demostra res sobre qui l'està utilitzant ara.

Aquesta bretxa és habitual en la majoria de productes i té conseqüències en una plataforma d'IA, on els actius darrere del compte són l'accés al model, els crèdits i la quota. Una clau API és un testimoni al portador — qui la té és el compte. Les claus es comparteixen dins dels equips, es peguen en repositoris, es venen i es prenen. Sis mesos després d'un onboarding net, "aquest compte va ser verificat" és una declaració sobre el passat.

L'autenticació biomètrica tanca aquesta bretxa. Re-verifica l'ésser humà real en el moment d'una acció privilegiada — sense documents, sense contrasenya, en menys de dos segons, 0,10 $ per autenticació.

Punts clau

• La verificació d'onboarding és una instantània. L'autenticació biomètrica és una comprovació en el moment que importa.
• Prova de vida més coincidència facial amb el retrat ja emmagatzemat de la verificació original de l'usuari. Sense documents, sense contrasenya.
• Només de sessió. No hi ha cap punt final /v3/biometric-auth/ — s'executa a través d'una sessió amb workflow_type=BIOMETRIC_AUTHENTICATION.
• El detall d'implementació crític: utilitzeu el mateix vendor_data que la verificació original de l'usuari, o la cara emmagatzemada no es podrà recuperar.
• Desencadenants adequats: augments de quota, concessions de crèdit, emissió de noves claus API, actualitzacions de nivell, addició de membres d'equip privilegiats i qualsevol alerta de comportament de la vostra capa de trànsit.
• 0,10 $ per autenticació, pagament per èxit, en menys de dos segons.

Per què la reautenticació pertany a una plataforma d'IA

Tres modes de fallada fan que la instantània d'onboarding sigui insuficient.

Compartició i revenda de claus. Una clau emesa a un desenvolupador verificat pot acabar en qualsevol lloc. El compte roman verificat; la persona que l'utilitza no és la persona que es va verificar. Aquest és el mecanisme pel qual un compte legítimament verificat es converteix en un punt d'entrada a una xarxa fraudulenta — i és invisible per a qualsevol control que només analitza l'onboarding.

Presa de control de comptes. Les credencials són objecte de phishing o s'introdueixen per força, i l'atacant hereta un compte verificat amb una reputació establerta i límits elevats. Un compte verificat és un objectiu de presa de control més atractiu, no menys atractiu.

Escalada a posteriori. El compte que es va verificar per a un accés modest al gener sol·licita un augment de quota de 50 vegades a l'agost. Res de la verificació de gener parla de la sol·licitud d'agost.

En els tres casos, l'estat de verificació del compte no ha canviat i la persona que hi ha darrere no és qui penses. Una contrasenya, un codi d'un sol ús o un testimoni de sessió no poden distingir aquests casos, perquè cada un d'ells és un atacant que posseeix legítimament la credencial. Només una comprovació biomètrica fa la pregunta que importa: és la persona que hi ha aquí ara mateix la persona que es va verificar?

Com funciona

L'autenticació biomètrica reutilitza els mateixos components LivenessV3 i FaceMatchV3 que el flux d'identitat regular. L'única diferència és d'on prové la imatge de referència — en lloc del retrat d'un document acabat d'enviar, utilitza el retrat ja emmagatzemat de la verificació prèvia de l'usuari.

És per això que no necessita documents i per què és prou ràpid i barat per encaixar en un flux de producte normal.

És només de sessió

No hi ha cap punt final dedicat /v3/biometric-auth/. L'autenticació es lliura mitjançant una sessió el flux de treball de la qual està configurat per a això — workflow_type=BIOMETRIC_AUTHENTICATION. Si busqueu un punt final autònom a la referència de l'API, és per això que no en trobeu cap.

El flux

1. Configureu un flux de treball de tipus BIOMETRIC_AUTHENTICATION a la consola i anoteu el seu workflow_id.
2. Creeu una sessió:

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. Envieu l'usuari a través de la sessió retornada — allotjada o incrustada amb qualsevol dels SDKs gratuïts.
2. Obteniu la decisió:

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

O subscriviu-vos a session.status.updated i preneu el webhook.

L'únic detall que trenca les integracions

Utilitzeu el mateix vendor_data que la verificació original de l'usuari.

Aquest valor és com Didit recupera el retrat emmagatzemat per fer la coincidència. Un vendor_data nou o diferent significa que no hi ha cap cara emmagatzemada per comparar, i el flux no pot fer el que heu demanat. Si necessiteu anul·lar deliberadament la referència emmagatzemada, passeu portrait_image explícitament — però el camí normal és un vendor_data estable per compte, establert en l'onboarding i reutilitzat per sempre.

Aquest és l'argument per tractar vendor_data com un identificador de primera classe al vostre propi esquema des del primer dia. També és el que fa que els resultats de la cerca facial es mapin de manera neta als vostres comptes.

Lectura del resultat

Els resultats arriben a liveness_checks i face_matches. Tots dos són sempre arrays — mai objectes singulars — i cada element porta un node_id perquè els fluxos de treball multi-instància puguin desambiguar els passos. Cada un és null fins que el seu pas ha produït dades.

Les advertències inclouen LOW_LIVENESS_SCORE, alertes d'atac facial, coincidències de llista negra i baixa similitud de coincidència facial. Els llindars i les accions de rebuig són configurables, de manera que podeu aplicar un barem més estricte per a una gran concessió de crèdit que per a una pujada de quota rutinària.

Què hauria de desencadenar un "step-up"

El valor d'aquest control depèn gairebé totalment del disseny del desencadenant. Massa i haureu creat una molèstia; massa pocs i mai s'activarà quan importi.

Escalada d'accés — augments de quota, concessions de crèdit, emissió de noves claus API, actualitzacions de nivell, canvi a un nivell de capacitat que considereu sensible.

Canvis de compte — un nou membre d'equip privilegiat, un canvi de propietari de facturació, un canvi de destinació de pagament, una contrasenya o restabliment de MFA.

Alertes de comportament — el desencadenant de més valor. Quan la vostra pròpia capa de trànsit marca un compte per a consultes concentrades o un patró amb forma de destil·lació, un "step-up" biomètric fa la pregunta que la capa de trànsit no pot: la persona verificada segueix sent la que opera aquest compte? Un "pass" redueix la interpretació. Una fallada o un abandonament és en si mateix un senyal fort.

Senyals d'enllaç — una sessió que porta DEVICE_RECOVERED_HIGH_CONFIDENCE, o una cara que coincideix amb un usuari verificat existent, ha guanyat un "step-up" independentment del que demani el compte.

Dormància més escalada — un compte tranquil durant mesos que de sobte sol·licita un gran augment. No només la dormància; la combinació.

Per què no només exigir una contrasenya o un codi?

Perquè cada factor convencional és una credencial al portador, i el model d'amenaça aquí és un atacant que posseeix la credencial.

Un codi d'un sol ús va al número de telèfon o adreça registrada — que l'atacant controla després d'una presa de control, i que el legítim compartidor de claus simplement reenvia. Una contrasenya demostra coneixement d'una cadena. Una clau de maquinari demostra possessió d'un objecte, que es pot lliurar amb la clau.

Una coincidència facial amb prova de vida demostra que una persona específica està present en aquest moment. Per vincular el privilegi a una persona, aquest és l'únic factor que respon a la pregunta real. A 0,10 $ i en menys de dos segons, també és prou barat per utilitzar-lo en desencadenants reals en lloc de guardar-lo per a emergències.

També val la pena assenyalar el que no fa. Reautenticar la persona darrere d'un compte no impedeix l'extracció de models i no la detecta. Un desenvolupador verificat encara pot fer un mal ús de l'accés que té. Això tanca la bretxa entre "aquest compte va ser verificat una vegada" i "aquesta persona és aquí ara" — una bretxa estreta i real. Els controls de sortida a nivell de model i la detecció de trànsit semàntic romanen capes separades, i segueixen sent vostres.

Casos d'ús

Plataformes API d'IA que restringeixen l'escalada de quota, les concessions de crèdit i l'emissió de claus darrere d'una comprovació de la persona.

Productes d'agent i automatització que requereixen un "step-up" abans que a un agent se li concedeixi una nova capacitat o s'augmenti un límit de despesa.

Serveis financers que reautentiquen abans d'una transferència de gran valor o un canvi de destinació de pagament.

Mercats que reverifiquen un venedor abans d'un canvi de mètode de pagament — el benefici més comú de la presa de control de comptes.

Qualsevol plataforma amb un flux de recuperació que utilitzi la reautenticació biomètrica en lloc de preguntes basades en el coneixement, que són el punt feble de la majoria dels dissenys de seguretat de comptes.

Preguntes freqüents

L'usuari ha de tornar a enviar un document?

No. Aquest és el punt. La comprovació es realitza amb el retrat ja emmagatzemat de la seva verificació original — prova de vida més coincidència facial, sense documents.

Què passa si l'usuari mai va ser verificat amb Didit?

Llavors no hi ha cap retrat emmagatzemat i no hi ha res amb què autenticar-se. L'autenticació biomètrica és una primitiva de reverificació; pressuposa una verificació anterior sota el mateix vendor_data.

Quant de temps triga?

Inferència en menys de dos segons. Des del punt de vista de l'usuari és un selfie i un moment.

Es pot executar dins de la nostra pròpia interfície?

Sí. Els SDK web, iOS, Android, React Native i Flutter són tots gratuïts, i White Label (0,20 $) elimina la marca Didit.

Què passa si algú mostra una foto o un vídeo del propietari del compte?

Per a això serveix la detecció de prova de vida. La prova de vida passiva de Didit té una avaluació de detecció d'atacs de presentació iBeta Nivell 1, i les alertes d'atac facial apareixen a les advertències. Els llindars són configurables.

Quant costa?

0,10 $ per autenticació, pagament per èxit, sense mínim.

Cada inici de sessió hauria de requerir això?

No. L'inici de sessió és el desencadenant equivocat — s'activa constantment i gairebé sempre per res. Adjunteu-lo a l'escalada de privilegis i a les alertes, on el cost d'equivocar-se és alt i la freqüència és baixa.

Preparat per començar?

Configureu un flux de treball, connecteu-lo als vostres punts d'escalada i reutilitzeu-lo a tot arreu.

• Llegiu la documentació — Visió general de l'autenticació biomètrica i l'API de sessions.
• Vegeu el producte — Verificació d'usuari.
• Consulteu els preus — 0,10 $ per autenticació, pagament per èxit, sense mínims.
• Comenceu gratis — business.didit.me, 500 verificacions KYC al mes sense cost.