> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Événements d'authentification et webhooks > Didit centralise l'activité de connexion : récapitulatif, chronologie, détection de fraude, règles d'événements et webhooks auth.*. > [!WARNING] > > 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/`](https://docs.didit.me/fr/transaction-monitoring/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](https://docs.didit.me/fr/authentication/bot-protection.md) (`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/`](https://docs.didit.me/fr/management-api/users/list) sous `authentication` : ```json theme={null} { "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](https://docs.didit.me/fr/transaction-monitoring/event-rules.md) 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](https://docs.didit.me/fr/integration/webhooks.md) 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. ```json auth.new_device theme={null} { "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](https://docs.didit.me/fr/integration/webhooks.md)). ## 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](https://docs.didit.me/fr/transaction-monitoring/events.md) et [envoi d'événements avec le SDK](https://docs.didit.me/fr/transaction-monitoring/sdk-event-submission.md). Utilisez le `vendor_data` de la personne, extrait de son token d'accès. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.