Eventi di autenticazione e webhook

L’autenticazione è una novità. Didit attiva la consegna degli eventi per la tua applicazione. Le azioni delle regole che disconnettono una persona o la bloccano non sono ancora attive: una regola che le usa registra l’azione senza applicarla.

Didit Authentication invia automaticamente a Didit la propria attività. Non devi inviare tu gli eventi di accesso. Ogni evento viene associato alla persona con lo stesso vendor_data, accanto alle sue verifiche e transazioni. Non inviare anche i tuoi eventi auth.login a /v3/events/ per gli stessi accessi. Verrebbero memorizzati due volte e non aggiornerebbero il riepilogo degli accessi della persona né invierebbero webhook auth.*.

Cosa viene inviato

Attività di accesso	Memorizzata come	Webhook
Registrazione	`auth.signup`	`auth.signup`
Accesso	`auth.login`	`auth.login`
Accesso non riuscito	`auth.login_failed`	`auth.login_failed`
Disconnessione o sessione revocata	`auth.logout`	Nessuno
Password dimenticata	`auth.password_forgot`	`auth.password_reset_requested`
Reimpostazione della password	`auth.password_reset`	`auth.password_reset_completed`
Password modificata	`security.password_changed`	Nessuno
Autenticatore aggiunto o modificato	`security.mfa_changed`	`auth.mfa_changed`
Accesso da un nuovo dispositivo	`security.device_changed`	`auth.new_device`
Account bloccato o a cui è stato impedito l’accesso	`security.account_locked`	`auth.account_locked`
Accesso dell’agente approvato o revocato	`security.agent_access_approved`, `security.agent_access_revoked`	Nessuno

Anche le decisioni della protezione dai bot (attempt_challenged, attempt_blocked e altre) vengono memorizzate come eventi auth.*, quindi compaiono nella cronologia. Un nuovo dispositivo è un dispositivo che non corrisponde né a un ID dispositivo né a un’impronta digitale con cui la persona abbia già effettuato l’accesso in precedenza. Ogni evento contiene:

il method di accesso (ad esempio password o passkey) e un reason per i tentativi non riusciti e i blocchi,
l’indirizzo IP e il contesto del dispositivo: un ID dispositivo persistente, un’impronta digitale, lo user agent e un punteggio bot, quando il client lo ha inviato,
l’ID della sessione.

Un accesso non riuscito con un identificativo sconosciuto o non verificato non ha vendor_data. Didit non riceve mai l’identificativo in sé, ma solo un hash con chiave. Questi tentativi non vengono mai collegati a una persona, ma le viste antifrode sottostanti li conteggiano comunque per account.

Dove visualizzarli

Il profilo della persona

Ogni persona ha un riepilogo degli accessi, mostrato nell’elenco Persone e nel profilo e restituito da /v3/users/ come authentication:

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

status è ACTIVE, LOCKED (bloccato da una policy di sicurezza) oppure BLOCKED (bloccato dal tuo team).
authentication è null per una persona senza identità di accesso.
Puoi filtrare Persone per stato di accesso, metodo di accesso (incluso “nessuno”) e MFA.

Eventi e cronologia

Gli eventi di accesso compaiono nella pagina Eventi della console e nella scheda Eventi di ogni persona. Per leggerli serve l’autorizzazione list:transactions o read:authentication. Aprendo un evento di accesso si vedono dispositivo e rete, l’eventuale motivo di protezione (ad esempio bots, stuffing, brute, vpn, travel o attack_mode) e le regole a cui l’evento corrispondeva.

Viste antifrode

La pagina Eventi include viste predefinite che combinano gli accessi con il resto dell’attività di una persona:

Vista	Cosa individua
Un dispositivo, più persone	3 o più persone su una stessa impronta digitale del dispositivo entro 7 giorni.
Picco di accessi non riusciti	Un IP pubblico con 10 o più accessi non riusciti su 3 o più account (24 ore per impostazione predefinita), con i suoi 30 minuti più intensi.
Nuovo dispositivo, poi un pagamento	Un accesso da un dispositivo non rilevato negli ultimi 90 giorni, seguito da un prelievo o da una transazione in uscita entro 15 minuti.
Password modificata, poi una transazione	Una transazione in uscita entro 30 minuti da una modifica della password.
Molte sessioni da un IP	3 o più sessioni di verifica per 3 o più persone in 48 ore.

Le viste considerano fino a 31 giorni di storico.

Regole sugli eventi

Gli eventi di accesso passano attraverso le stesse regole sugli eventi degli altri tuoi eventi. Il pacchetto Authentication fraud contiene quattro preimpostazioni:

Preset	Individua	Azioni
Account takeover	Una modifica della password o dell’MFA dopo 3 o più accessi non riusciti e un nuovo dispositivo entro 1 ora.	Rifiuta (punteggio 90), tag, disconnetti, blocca
Credential stuffing	Un accesso riuscito da un indirizzo IP con 10 o più accessi non riusciti su 3 o più account entro 1 ora.	Revisione (punteggio 60), tag, disconnetti
Nuovo dispositivo, poi un pagamento	Un prelievo entro 15 minuti da un nuovo dispositivo.	Revisione (punteggio 60), tag, disconnetti
Viaggio impossibile	Più di 500 km tra due accessi a una velocità superiore a 1.000 km/h.	Revisione (punteggio 50), tag, disconnetti

I campi utili per le tue regole includono 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 e event.ip.travel_speed_kmh. Le regole sugli eventi hanno due sole azioni riservate agli eventi di accesso: Disconnetti la persona da tutte le sessioni e Blocca l’accesso della persona. Non sono ancora attive. Finché non lo saranno, una regola le registra con lo stato DISABLED senza applicarle. Le altre azioni (punteggio, stato, tag, note, liste e casi) funzionano normalmente.

Webhook

Iscrivi una destinazione webhook ai tipi auth.* che ti servono. Solo le destinazioni iscritte li ricevono. Usa Try Webhook nella console per inviare un esempio di ogni 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"
  }
}

Deduplica su auth_event.event_id, l’ID dell’evento di accesso stesso: resta lo stesso per ogni consegna di quell’evento. auth_event.event_uuid permette di rileggere l’evento memorizzato tramite GET /v3/events/{event_uuid}/.
vendor_data, vendor_user_id e authentication sono null per un tentativo che non indica alcuna persona nota.
Verifica la firma come per ogni webhook di Didit (vedi webhook).

Fatturazione

Gli eventi di autenticazione non vengono fatturati per evento. L’autenticazione viene fatturata in base agli utenti attivi mensili.

Eventi gestiti dalla tua applicazione

Per le azioni che avvengono nel tuo prodotto, come una modifica del profilo o una richiesta di pagamento, invia gli eventi tu stesso dal tuo server (POST /v3/events/ con x-api-key) oppure dal dispositivo con un token di monitoraggio con ambito limitato. Consulta eventi e invio di eventi tramite SDK. Usa il vendor_data della persona dal suo token di accesso.

Guide

Autenticazione

Model Context Protocol (MCP)

SDK web

SDK nativi

SDK server

Integrazioni

Eventi di autenticazione e webhook

Cosa viene inviato

Dove visualizzarli

Il profilo della persona

Eventi e cronologia

Viste antifrode

Regole sugli eventi

Webhook

Fatturazione

Eventi gestiti dalla tua applicazione

​Cosa viene inviato

​Dove visualizzarli

​Il profilo della persona

​Eventi e cronologia

​Viste antifrode

​Regole sugli eventi

​Webhook

​Fatturazione

​Eventi gestiti dalla tua applicazione

Cosa viene inviato

Dove visualizzarli

Il profilo della persona

Eventi e cronologia

Viste antifrode

Regole sugli eventi

Webhook

Fatturazione

Eventi gestiti dalla tua applicazione