Autenticación Biométrica Reforzada para Acceso a API de IA: Vinculando Privilegios a una Persona (ES)

La verificación en la incorporación prueba quién creó una cuenta. No prueba nada sobre quién la está usando ahora.

Esa brecha es común en la mayoría de los productos y trascendental en una plataforma de IA, donde los activos detrás de la cuenta son el acceso al modelo, los créditos y la cuota. Una clave API es un token de portador; quien la tenga es la cuenta. Las claves se comparten dentro de los equipos, se pegan en repositorios, se venden y se apoderan de ellas. Seis meses después de una incorporación limpia, "esta cuenta fue verificada" es una afirmación sobre el pasado.

La autenticación biométrica cierra esa brecha. Reverifica al humano real en el momento de una acción privilegiada — sin documentos, sin contraseña, en menos de dos segundos, $0.10 por autenticación.

Puntos clave

• La verificación de incorporación es una instantánea. La autenticación biométrica es una verificación en el momento en que importa.
• Prueba de vida más coincidencia facial contra el retrato ya almacenado de la verificación original del usuario. Sin documentos, sin contraseña.
• Solo por sesión. No hay un punto final /v3/biometric-auth/ — se ejecuta a través de una sesión con workflow_type=BIOMETRIC_AUTHENTICATION.
• El detalle de implementación crítico: use el mismo vendor_data que la verificación original del usuario, o la cara almacenada no podrá recuperarse.
• Activadores correctos: aumentos de cuota, concesión de créditos, emisión de nuevas claves API, actualizaciones de nivel, adición de miembros de equipo privilegiados y cualquier alerta de comportamiento de su capa de tráfico.
• $0.10 por autenticación, pago por éxito, en menos de dos segundos.

Por qué la reautenticación pertenece a una plataforma de IA

Tres modos de falla hacen que la instantánea de incorporación sea insuficiente.

Compartir y revender claves. Una clave emitida a un desarrollador verificado puede terminar en cualquier lugar. La cuenta permanece verificada; la persona que la usa no es la persona que verificó. Este es el mecanismo por el cual una cuenta legítimamente verificada se convierte en un punto de entrada a una red cultivada, y es invisible para cualquier control que solo mire la incorporación.

Toma de cuentas. Las credenciales son víctimas de phishing o relleno de credenciales, y el atacante hereda una cuenta verificada con una reputación establecida y límites elevados. Una cuenta verificada es un objetivo de toma de control más atractivo, no menos atractivo.

Escalada posterior. La cuenta que se verificó para un acceso modesto en enero solicita un aumento de cuota de 50x en agosto. Nada de la verificación de enero se refiere a la solicitud de agosto.

En los tres casos, el estado de verificación de la cuenta no ha cambiado y el humano detrás de ella no es quien usted cree. Una contraseña, un código de un solo uso o un token de sesión no pueden distinguir estos casos, porque cada uno de ellos es un atacante que posee legítimamente la credencial. Solo una verificación biométrica plantea la pregunta que importa: ¿la persona que está aquí ahora es la persona que verificó?

Cómo funciona

La autenticación biométrica reutiliza los mismos componentes LivenessV3 y FaceMatchV3 que el flujo de identidad regular. La única diferencia es de dónde proviene la imagen de referencia — en lugar del retrato en un documento recién enviado, utiliza el retrato ya almacenado de la verificación anterior del usuario.

Por eso no necesita documentos, y por eso es lo suficientemente rápida y barata como para incluirla en un flujo de producto normal.

Es solo por sesión

No hay un punto final dedicado /v3/biometric-auth/. La autenticación se entrega a través de una sesión cuyo flujo de trabajo está configurado para ello — workflow_type=BIOMETRIC_AUTHENTICATION. Si busca un punto final independiente en la referencia de la API, es por eso que no puede encontrar uno.

El flujo

1. Configure un flujo de trabajo de tipo BIOMETRIC_AUTHENTICATION en la consola y anote su workflow_id.
2. Cree una sesión:

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. Envíe al usuario a través de la sesión devuelta — alojada o incrustada con cualquiera de los SDK gratuitos.
2. Obtenga la decisión:

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

O suscríbase a session.status.updated y tome el webhook.

El único detalle que rompe las integraciones

Use el mismo vendor_data que la verificación original del usuario.

Ese valor es cómo Didit recupera el retrato almacenado para comparar. Un vendor_data nuevo o diferente significa que no hay una cara almacenada para comparar, y el flujo no puede hacer lo que usted solicitó. Si necesita anular deliberadamente la referencia almacenada, pase portrait_image explícitamente, pero la ruta normal es un vendor_data estable por cuenta, establecido en la incorporación y reutilizado para siempre.

Este es el argumento para tratar vendor_data como un identificador de primera clase en su propio esquema desde el primer día. También es lo que hace que los resultados de la Búsqueda Facial se asignen limpiamente a sus cuentas.

Lectura del resultado

Los resultados llegan en liveness_checks y face_matches. Ambos son siempre matrices — nunca objetos singulares — y cada elemento lleva un node_id para que los flujos de trabajo de múltiples instancias puedan desambiguar los pasos. Cada uno es null hasta que su paso haya producido datos.

Las advertencias incluyen LOW_LIVENESS_SCORE, alertas de ataque facial, coincidencias con listas de bloqueo y baja similitud de coincidencia facial. Los umbrales y las acciones de rechazo son configurables, por lo que puede aplicar un estándar más estricto para una gran concesión de crédito que para un aumento de cuota rutinario.

Qué debería activar una autenticación reforzada

El valor de este control depende casi por completo del diseño del activador. Demasiados y habrá creado una molestia; muy pocos y nunca se activará cuando importa.

Escalada de acceso — aumentos de cuota, concesión de créditos, emisión de nuevas claves API, actualizaciones de nivel, paso a un nivel de capacidad que considere sensible.

Cambios en la cuenta — un nuevo miembro del equipo privilegiado, un cambio de propietario de facturación, un cambio de destino de pago, un restablecimiento de contraseña o MFA.

Alertas de comportamiento — el activador de mayor valor. Cuando su propia capa de tráfico marca una cuenta por consultas concentradas o un patrón con forma de destilación, una autenticación biométrica reforzada plantea la única pregunta que la capa de tráfico no puede: ¿sigue siendo el humano verificado el que opera esta cuenta? Un aprobado reduce la interpretación. Un fallo o un abandono es en sí mismo una señal fuerte.

Señales de vinculación — una sesión que lleva DEVICE_RECOVERED_HIGH_CONFIDENCE, o una cara que coincide con un usuario verificado existente, ha merecido una autenticación reforzada independientemente de lo que solicite la cuenta.

Inactividad más escalada — una cuenta inactiva durante meses que de repente solicita un gran aumento. No solo la inactividad; la combinación.

¿Por qué no simplemente requerir una contraseña o un código?

Porque cada factor convencional es una credencial de portador, y el modelo de amenaza aquí es un atacante que posee la credencial.

Un código de un solo uso va al número de teléfono o dirección en el archivo — que el atacante controla después de una toma de control, y que el que comparte la clave legítimamente simplemente reenvía. Una contraseña prueba el conocimiento de una cadena. Una clave de hardware prueba la posesión de un objeto, que puede entregarse con la clave.

Una coincidencia facial con prueba de vida demuestra que un ser humano específico está presente en este momento. Para vincular el privilegio a una persona, ese es el único factor que responde a la pregunta real. A $0.10 y en menos de dos segundos, también es lo suficientemente barato como para usarlo en activadores reales en lugar de guardarlo para emergencias.

Lo que no hace también vale la pena mencionarlo. Reautenticar al humano detrás de una cuenta no previene la extracción de modelos y no la detecta. Un desarrollador verificado aún puede hacer un mal uso del acceso que tiene. Esto cierra la brecha entre "esta cuenta fue verificada una vez" y "este humano está aquí ahora" — una brecha estrecha y real. Los controles de salida a nivel de modelo y la detección de tráfico semántico siguen siendo capas separadas, y siguen siendo suyas.

Casos de uso

Plataformas de API de IA que limitan la escalada de cuota, la concesión de créditos y la emisión de claves detrás de una verificación del humano.

Productos de agentes y automatización que requieren una autenticación reforzada antes de que se le conceda una nueva capacidad a un agente o se aumente un límite de gasto.

Servicios financieros que se reautentican antes de una transferencia de alto valor o un cambio de destino de pago.

Mercados que reverifican a un vendedor antes de un cambio de método de pago — la recompensa más común de la toma de cuentas.

Cualquier plataforma con un flujo de recuperación que utilice la reautenticación biométrica en lugar de preguntas basadas en el conocimiento, que son el eslabón más débil en la mayoría de los diseños de seguridad de cuentas.

Preguntas frecuentes

¿Necesita el usuario volver a enviar un documento?

No. Ese es el punto. La verificación se realiza contra el retrato ya almacenado de su verificación original — prueba de vida más coincidencia facial, sin documentos.

¿Qué pasa si el usuario nunca fue verificado con Didit?

Entonces no hay un retrato almacenado y no hay nada contra lo que autenticar. La autenticación biométrica es una primitiva de reverificación; presupone una verificación anterior bajo el mismo vendor_data.

¿Cuánto tiempo lleva?

Inferencias en menos de dos segundos. Desde el punto de vista del usuario, es un selfie y un momento.

¿Puede ejecutarse dentro de nuestra propia interfaz?

Sí. Los SDK web, iOS, Android, React Native y Flutter son todos gratuitos, y White Label ($0.20) elimina la marca Didit.

¿Qué pasa si alguien sostiene una foto o un video del propietario de la cuenta?

Para eso sirve la detección de prueba de vida. La prueba de vida pasiva de Didit cuenta con una evaluación de detección de ataque de presentación iBeta Nivel 1, y las alertas de ataque facial aparecen en las advertencias. Los umbrales son configurables.

¿Cuánto cuesta?

$0.10 por autenticación, pago por éxito, sin mínimos.

¿Debería cada inicio de sesión requerir esto?

No. El inicio de sesión es el activador incorrecto — se activa constantemente y en su mayoría sin motivo. Vincúlelo a la escalada de privilegios y a las alertas, donde el costo de equivocarse es alto y la frecuencia es baja.

¿Listo para empezar?

Configure un flujo de trabajo, conéctelo a sus puntos de escalada y reutilícelo en todas partes.

• Lea la documentación — Descripción general de la autenticación biométrica y la API de Sesiones.
• Vea el producto — Verificación de Usuario.
• Consulte los precios — $0.10 por autenticación, pago por éxito, sin mínimos.
• Empiece gratis — business.didit.me, 500 verificaciones KYC al mes sin costo.