Événements d'authentification et webhooks

Authentication est une fonctionnalité récente. Didit active la livraison des événements pour votre application. Les actions de règles qui déconnectent une personne ou la bloquent ne sont pas encore actives : une règle qui les utilise enregistre l’action sans l’appliquer.

Didit Authentication transmet automatiquement sa propre activité à Didit. Vous n’avez pas besoin d’envoyer vous-même les événements de connexion. Chaque événement est associé à la personne disposant du même vendor_data, aux côtés de ses vérifications et de ses transactions. N’envoyez pas non plus vos propres événements auth.login vers /v3/events/ pour ces mêmes connexions. Ils seraient stockés deux fois, et ils ne mettent pas à jour le récapitulatif de connexion de la personne ni n’envoient de webhooks auth.*.

Ce qui est envoyé

Activité de connexion	Stocké sous forme de	Webhook
Inscription	`auth.signup`	`auth.signup`
Connexion	`auth.login`	`auth.login`
Échec de connexion	`auth.login_failed`	`auth.login_failed`
Déconnexion, ou révocation d’une session	`auth.logout`	Aucun
Mot de passe oublié	`auth.password_forgot`	`auth.password_reset_requested`
Réinitialisation du mot de passe	`auth.password_reset`	`auth.password_reset_completed`
Mot de passe modifié	`security.password_changed`	Aucun
Authentificateur ajouté ou modifié	`security.mfa_changed`	`auth.mfa_changed`
Connexion depuis un nouvel appareil	`security.device_changed`	`auth.new_device`
Compte verrouillé ou bloqué	`security.account_locked`	`auth.account_locked`
Accès d’agent approuvé ou révoqué	`security.agent_access_approved`, `security.agent_access_revoked`	Aucun

Les décisions de protection contre les bots (attempt_challenged, attempt_blocked et autres) sont également stockées sous forme d’événements auth.*, et apparaissent donc dans la chronologie. Un nouvel appareil est un appareil qui ne correspond ni à un identifiant d’appareil ni à une empreinte utilisés auparavant par la personne pour se connecter. Chaque événement contient :

la méthode de connexion method (par exemple password ou passkey) et un motif reason pour les échecs et les verrouillages,
l’adresse IP et le contexte de l’appareil : un identifiant d’appareil persistant, une empreinte, l’agent utilisateur et un score de bot lorsque le client en a envoyé un,
l’identifiant de session.

Un échec de connexion pour un identifiant inconnu ou non vérifié ne possède pas de vendor_data. Didit ne reçoit jamais l’identifiant lui-même, uniquement son hachage avec clé. Ces tentatives ne sont jamais associées à une personne, mais les vues sur la fraude présentées ci-dessous les comptabilisent tout de même par compte.

Où les consulter

Profil de la personne

Chaque personne dispose d’un récapitulatif de connexion, affiché dans la liste Personnes et sur le profil, et renvoyé sur /v3/users/ sous authentication :

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

status est défini sur ACTIVE, LOCKED (verrouillé par une politique de sécurité) ou BLOCKED (bloqué par votre équipe).
authentication vaut null pour une personne sans identité de connexion.
Vous pouvez filtrer Personnes par statut de connexion, méthode de connexion (y compris « none ») et MFA.

Événements et chronologie

Les événements de connexion apparaissent sur la page Événements de la console et sur l’onglet Événements de chaque personne. Leur consultation nécessite l’autorisation list:transactions ou read:authentication. Ouvrir un événement de connexion affiche son appareil et son réseau, tout motif de protection (par exemple bots, stuffing, brute, vpn, travel ou attack_mode), ainsi que les règles auxquelles il correspondait.

Vues sur la fraude

La page Événements propose des vues prêtes à l’emploi qui combinent les connexions avec le reste de l’activité d’une personne :

Vue	Ce qu’elle détecte
Un appareil, plusieurs personnes	3 personnes ou plus sur une même empreinte d’appareil en 7 jours.
Pic d’échecs de connexion	Une adresse IP publique avec 10 échecs de connexion ou plus sur 3 comptes ou plus (24 heures par défaut), avec ses 30 minutes les plus actives.
Nouvel appareil, puis paiement sortant	Une connexion depuis un appareil non vu depuis 90 jours, suivie d’un retrait ou d’une transaction sortante dans les 15 minutes.
Mot de passe modifié, puis transaction	Une transaction sortante dans les 30 minutes suivant un changement de mot de passe.
Plusieurs sessions depuis une même IP	3 sessions de vérification ou plus pour 3 personnes ou plus en 48 heures.

Les vues couvrent un historique allant jusqu’à 31 jours.

Règles d’événements

Les événements de connexion passent par les mêmes règles d’événements que vos autres événements. L’ensemble Fraude liée à l’authentification comprend quatre préconfigurations :

Préconfiguration	Correspondance	Actions
Prise de contrôle de compte	Un changement de mot de passe ou de MFA après 3 échecs de connexion ou plus et un nouvel appareil en moins d’une heure.	Refuser (score 90), taguer, déconnecter, bloquer
Bourrage d’identifiants	Une connexion réussie depuis une adresse IP avec 10 échecs ou plus sur 3 comptes ou plus en moins d’une heure.	Examiner (score 60), taguer, déconnecter
Nouvel appareil, puis paiement sortant	Un retrait dans les 15 minutes suivant un nouvel appareil.	Examiner (score 60), taguer, déconnecter
Déplacement impossible	Plus de 500 km entre deux connexions à plus de 1 000 km/h.	Examiner (score 50), taguer, déconnecter

Parmi les champs utiles pour vos propres règles figurent 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 et event.ip.travel_speed_kmh. Les règles d’événements comportent deux actions spécifiques aux événements de connexion : Déconnecter la personne de toutes ses sessions et Empêcher la personne de se connecter. Elles ne sont pas encore actives. D’ici là, une règle les enregistre avec le statut DISABLED et ne les applique pas. Les autres actions (score, statut, tags, notes, listes et dossiers) fonctionnent comme d’habitude.

Webhooks

Abonnez une destination de webhook aux types auth.* dont vous avez besoin. Seules les destinations abonnées les reçoivent. Utilisez Essayer le webhook dans la console pour envoyer un exemple de chaque type.

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"
  }
}

Dédupliquez sur auth_event.event_id, l’identifiant propre à l’événement de connexion : il reste identique pour chaque livraison de cet événement. auth_event.event_uuid permet de récupérer l’événement stocké via GET /v3/events/{event_uuid}/.
vendor_data, vendor_user_id et authentication valent null pour une tentative ne désignant aucune personne connue.
Vérifiez la signature comme pour n’importe quel webhook Didit (voir les webhooks).

Facturation

Les événements d’authentification ne sont pas facturés par événement. L’authentification est facturée par utilisateur actif mensuel.

Événements appartenant à votre application

Pour les actions qui ont lieu dans votre propre produit, comme une modification de profil ou une demande de virement, soumettez vous-même les événements depuis votre serveur (POST /v3/events/ avec x-api-key) ou depuis l’appareil avec un token de surveillance à portée limitée. Consultez les événements et envoi d’événements avec le SDK. Utilisez le vendor_data de la personne, extrait de son token d’accès.

Guides

Authentification

Model Context Protocol (MCP)

SDK web

SDK natifs

SDK serveur

Intégrations

Événements d'authentification et webhooks

Ce qui est envoyé

Où les consulter

Profil de la personne

Événements et chronologie

Vues sur la fraude

Règles d’événements

Webhooks

Facturation

Événements appartenant à votre application

​Ce qui est envoyé

​Où les consulter

​Profil de la personne

​Événements et chronologie

​Vues sur la fraude

​Règles d’événements

​Webhooks

​Facturation

​Événements appartenant à votre application

Ce qui est envoyé

Où les consulter

Profil de la personne

Événements et chronologie

Vues sur la fraude

Règles d’événements

Webhooks

Facturation

Événements appartenant à votre application