Eventos de autenticación y webhooks

Authentication es una función nueva. Didit activa la entrega de eventos para tu aplicación. Las acciones de regla que cierran la sesión de una persona o la bloquean todavía no están activas: una regla que las usa registra la acción sin aplicarla.

Didit Authentication envía su propia actividad a Didit automáticamente. No tienes que enviar tú los eventos de inicio de sesión. Cada evento se asigna a la persona que tiene el mismo vendor_data, junto a sus verificaciones y transacciones. No publiques además tus propios eventos auth.login en /v3/events/ para los mismos inicios de sesión. Se almacenarían dos veces y no actualizarían el resumen de inicio de sesión de la persona ni envían webhooks auth.*.

Qué se envía

Actividad de inicio de sesión	Se almacena como	Webhook
Registro	`auth.signup`	`auth.signup`
Inicio de sesión	`auth.login`	`auth.login`
Inicio de sesión fallido	`auth.login_failed`	`auth.login_failed`
Cierre de sesión, o una sesión revocada	`auth.logout`	Ninguno
Contraseña olvidada	`auth.password_forgot`	`auth.password_reset_requested`
Restablecimiento de contraseña	`auth.password_reset`	`auth.password_reset_completed`
Contraseña cambiada	`security.password_changed`	Ninguno
Autenticador añadido o cambiado	`security.mfa_changed`	`auth.mfa_changed`
Inicio de sesión desde un dispositivo nuevo	`security.device_changed`	`auth.new_device`
Cuenta bloqueada o deshabilitada	`security.account_locked`	`auth.account_locked`
Acceso de agente aprobado o revocado	`security.agent_access_approved`, `security.agent_access_revoked`	Ninguno

Las decisiones de protección contra bots (attempt_challenged, attempt_blocked y otras) también se almacenan como eventos auth.*, por lo que aparecen en la línea de tiempo. Un dispositivo nuevo es un dispositivo que no coincide ni con un ID de dispositivo ni con una huella digital desde los que la persona haya iniciado sesión antes. Cada evento incluye:

el method de inicio de sesión (por ejemplo, password o passkey) y un reason para los fallos y bloqueos,
la dirección IP y el contexto del dispositivo: un ID de dispositivo persistente, una huella digital, el user agent y una puntuación de bot cuando el cliente la envió,
el ID de sesión.

Un inicio de sesión fallido para un identificador desconocido o no verificado no tiene vendor_data. Didit nunca recibe el identificador en sí, solo un hash de este generado con una clave. Estos intentos nunca se vinculan a una persona, pero las vistas de fraude que se describen más abajo los siguen contando por cuenta.

Dónde los ves

El perfil de la persona

Cada persona tiene un resumen de inicio de sesión, que se muestra en la lista y el perfil de Personas y se devuelve en /v3/users/ como authentication:

{
  "authentication": {
    "status": "ACTIVE",
    "methods": ["password", "passkey"],
    "mfa_enabled": true,
    "last_sign_in_at": "2026-10-14T09:12:44Z"
  }
}

status es ACTIVE, LOCKED (bloqueada por una política de seguridad) o BLOCKED (bloqueada por tu equipo).
authentication es null para una persona sin identidad de inicio de sesión.
Puedes filtrar Personas por estado de inicio de sesión, método de inicio de sesión (incluido “ninguno”) y MFA.

Eventos y línea de tiempo

Los eventos de inicio de sesión aparecen en la página Eventos de la consola y en la pestaña Eventos de cada persona. Para leerlos se necesita el permiso list:transactions o read:authentication. Al abrir un evento de inicio de sesión se muestran su dispositivo y su red, cualquier motivo de protección (por ejemplo, bots, stuffing, brute, vpn, travel o attack_mode) y las reglas con las que coincidió.

Vistas de fraude

La página Eventos tiene vistas predefinidas que combinan los inicios de sesión con el resto de la actividad de una persona:

Vista	Qué detecta
Un dispositivo, varias personas	3 o más personas con una misma huella digital de dispositivo en un plazo de 7 días.
Pico de inicios de sesión fallidos	Una IP pública con 10 o más inicios de sesión fallidos contra 3 o más cuentas (24 horas por defecto), con sus 30 minutos de mayor actividad.
Dispositivo nuevo y después un retiro	Un inicio de sesión desde un dispositivo no visto en 90 días y, a continuación, un retiro o una transacción saliente en un plazo de 15 minutos.
Contraseña cambiada y después una transacción	Una transacción saliente en los 30 minutos siguientes a un cambio de contraseña.
Muchas sesiones desde una IP	3 o más sesiones de verificación para 3 o más personas en 48 horas.

Las vistas consultan datos de hasta 31 días atrás.

Reglas de eventos

Los eventos de inicio de sesión pasan por las mismas reglas de eventos que el resto de tus eventos. El paquete Authentication fraud tiene cuatro preajustes:

Preajuste	Coincide con	Acciones
Toma de control de cuenta	Un cambio de contraseña o de MFA después de 3 o más inicios de sesión fallidos y un dispositivo nuevo en un plazo de 1 hora.	Rechazar (puntuación 90), etiquetar, cerrar sesión, bloquear
Relleno de credenciales	Un inicio de sesión exitoso desde una IP con 10 o más fallos en 3 o más cuentas en un plazo de 1 hora.	Revisión (puntuación 60), etiquetar, cerrar sesión
Dispositivo nuevo y después un retiro	Un retiro en los 15 minutos siguientes a un dispositivo nuevo.	Revisión (puntuación 60), etiquetar, cerrar sesión
Viaje imposible	Más de 500 km entre inicios de sesión a más de 1000 km/h.	Revisión (puntuación 50), etiquetar, cerrar sesión

Entre los campos útiles para tus propias reglas están event.category, event.action_type, event.payload.method, event.payload.reason, event.security.changed_field, event.device.fingerprint, event.device.persistent_device_id, event.device.bot_score, event.ip.is_vpn_or_tor, event.ip.is_data_center, event.ip.country, event.ip.travel_distance_km y event.ip.travel_speed_kmh. Las reglas de eventos tienen dos acciones exclusivas de los eventos de inicio de sesión: Sign the person out of every session y Block the person from signing in. Todavía no están activas. Hasta que lo estén, una regla las registra con el estado DISABLED y no las aplica. Las demás acciones (puntuación, estado, etiquetas, notas, listas y casos) funcionan como de costumbre.

Webhooks

Suscribe un destino de webhook a los tipos auth.* que necesites. Solo los destinos suscritos los reciben. Usa Try Webhook en la consola para enviar una muestra de cada tipo.

auth.new_device

{
  "webhook_type": "auth.new_device",
  "event_id": "0b6f2a71-3c4d-4e5f-8a9b-0c1d2e3f4a5b",
  "application_id": "11111111-2222-3333-4444-555555555555",
  "environment": "live",
  "timestamp": 1760433164,
  "created_at": 1760433164,
  "vendor_user_id": "8f0c3a52-4b7e-4a51-9a56-1f2d3c4b5a69",
  "vendor_data": "user-1234",
  "auth_event": {
    "event_id": "auth:3d0f1c2e-7a8b-4c5d-9e0f-1a2b3c4d5e6f",
    "event_uuid": "5b6c7d8e-9f01-4a2b-8c3d-4e5f60718293",
    "type": "security.device_changed",
    "method": "passkey",
    "reason": null,
    "occurred_at": "2026-10-14T09:12:44+00:00",
    "ip_address": "203.0.113.10",
    "device": {
      "fingerprint": "fp_7f3a",
      "label": "Chrome on Android",
      "persistent_device_id": "dev_4c21"
    }
  },
  "authentication": {
    "status": "ACTIVE",
    "methods": ["passkey"],
    "mfa_enabled": true,
    "last_sign_in_at": "2026-10-14T09:12:44Z"
  }
}

Elimina duplicados con auth_event.event_id, el ID propio del evento de inicio de sesión: se mantiene igual en cada entrega de ese evento. auth_event.event_uuid permite recuperar el evento almacenado mediante GET /v3/events/{event_uuid}/.
vendor_data, vendor_user_id y authentication son null para un intento que no indica a ninguna persona conocida.
Verifica la firma igual que para cualquier webhook de Didit (consulta webhooks).

Facturación

Los eventos de autenticación no se facturan por evento. La autenticación se factura por usuario activo mensual.

Eventos que gestiona tu aplicación

Para las acciones que ocurren en tu propio producto, como un cambio de perfil o una solicitud de pago, envía tú mismo los eventos desde tu servidor (POST /v3/events/ con x-api-key) o desde el dispositivo con un token de monitorización con ámbito limitado. Consulta eventos y envío de eventos desde el SDK. Usa el vendor_data de la persona incluido en su token de acceso.

Guías

Autenticación

Model Context Protocol (MCP)

SDKs web

SDKs nativos

SDK de servidor

Integraciones

Eventos de autenticación y webhooks

Qué se envía

Dónde los ves

El perfil de la persona

Eventos y línea de tiempo

Vistas de fraude

Reglas de eventos

Webhooks

Facturación

Eventos que gestiona tu aplicación

​Qué se envía

​Dónde los ves

​El perfil de la persona

​Eventos y línea de tiempo

​Vistas de fraude

​Reglas de eventos

​Webhooks

​Facturación

​Eventos que gestiona tu aplicación

Qué se envía

Dónde los ves

El perfil de la persona

Eventos y línea de tiempo

Vistas de fraude

Reglas de eventos

Webhooks

Facturación

Eventos que gestiona tu aplicación