Authentifizierungsereignisse und Webhooks

Die Authentifizierung ist neu. Didit aktiviert die Ereigniszustellung für Ihre Anwendung. Die Regelaktionen, die eine Person abmelden oder sperren, sind noch nicht aktiv: Eine Regel, die sie verwendet, protokolliert die Aktion, wendet sie aber nicht an.

Didit Authentication sendet seine Aktivitäten automatisch an Didit. Anmeldeereignisse müssen Sie nicht selbst übermitteln. Jedes Ereignis wird der Person mit demselben vendor_data zugeordnet, zusammen mit ihren Verifizierungen und Transaktionen. Senden Sie für dieselben Anmeldungen nicht zusätzlich Ihre eigenen auth.login-Ereignisse an /v3/events/. Sie würden doppelt gespeichert, und sie aktualisieren weder die Anmeldezusammenfassung der Person noch lösen sie auth.*-Webhooks aus.

Was gesendet wird

Anmeldeaktivität	Gespeichert als	Webhook
Registrierung	`auth.signup`	`auth.signup`
Anmeldung	`auth.login`	`auth.login`
Fehlgeschlagene Anmeldung	`auth.login_failed`	`auth.login_failed`
Abmeldung oder widerrufene Sitzung	`auth.logout`	Keiner
Passwort vergessen	`auth.password_forgot`	`auth.password_reset_requested`
Passwort zurückgesetzt	`auth.password_reset`	`auth.password_reset_completed`
Passwort geändert	`security.password_changed`	Keiner
Authenticator hinzugefügt oder geändert	`security.mfa_changed`	`auth.mfa_changed`
Anmeldung von einem neuen Gerät	`security.device_changed`	`auth.new_device`
Konto gesperrt oder blockiert	`security.account_locked`	`auth.account_locked`
Agentenzugriff genehmigt oder widerrufen	`security.agent_access_approved`, `security.agent_access_revoked`	Keiner

Bot-Schutz-Entscheidungen (attempt_challenged, attempt_blocked und weitere) werden ebenfalls als auth.*-Ereignisse gespeichert, sodass sie in der Zeitleiste erscheinen. Ein neues Gerät ist ein Gerät, das weder mit einer Geräte-ID noch mit einem Fingerprint übereinstimmt, mit dem sich die Person zuvor angemeldet hat. Jedes Ereignis enthält:

die Anmeldemethode method (zum Beispiel password oder passkey) und einen reason für Fehlschläge und Sperren,
die Adresse sowie den Gerätekontext: eine dauerhafte Geräte-ID, einen Fingerprint, den User-Agent und einen Bot-Score, sofern der Client diesen übermittelt hat,
die Sitzungs-ID.

Eine fehlgeschlagene Anmeldung mit einer unbekannten oder nicht nachgewiesenen Kennung hat kein vendor_data. Didit erhält die Kennung selbst nie, sondern nur einen schlüsselbasierten Hash davon. Diese Versuche werden nie einer Person zugeordnet, die Betrugsansichten unten zählen sie jedoch pro Konto.

Wo Sie sie sehen

Das Profil der Person

Jede Person erhält eine Anmeldezusammenfassung. Sie wird in der Liste und im Profil von Personen angezeigt und über /v3/users/ als authentication zurückgegeben:

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

status ist ACTIVE, LOCKED (durch eine Sicherheitsrichtlinie gesperrt) oder BLOCKED (durch Ihr Team blockiert).
authentication ist bei einer Person ohne Anmeldeidentität null.
Sie können Personen nach Anmeldestatus, Anmeldemethode (einschließlich „none“) und MFA filtern.

Ereignisse und Zeitleiste

Anmeldeereignisse erscheinen auf der Konsolenseite Ereignisse und auf dem Tab Ereignisse jeder Person. Zum Lesen benötigen Sie die Berechtigung list:transactions oder read:authentication. Wenn Sie ein Anmeldeereignis öffnen, werden das Gerät und das Netzwerk angezeigt, ein etwaiger Schutzgrund (zum Beispiel bots, stuffing, brute, vpn, travel oder attack_mode) sowie die Regeln, auf die es zutraf.

Betrugsansichten

Auf der Seite Ereignisse stehen fertige Ansichten zur Verfügung, die Anmeldungen mit der übrigen Aktivität einer Person kombinieren:

Ansicht	Was sie findet
Ein Gerät, mehrere Personen	3 oder mehr Personen auf einem Geräte-Fingerprint innerhalb von 7 Tagen.
Anstieg fehlgeschlagener Anmeldungen	Eine öffentliche Adresse mit 10 oder mehr fehlgeschlagenen Anmeldungen bei 3 oder mehr Konten (standardmäßig 24 Stunden), mit dem 30-minütigen Zeitraum mit den meisten fehlgeschlagenen Anmeldungen.
Neues Gerät, dann eine Auszahlung	Eine Anmeldung von einem Gerät, das seit 90 Tagen nicht gesehen wurde, gefolgt von einer Auszahlung oder ausgehenden Transaktion innerhalb von 15 Minuten.
Passwort geändert, dann eine Transaktion	Eine ausgehende Transaktion innerhalb von 30 Minuten nach einer Passwortänderung.
Viele Sitzungen von einer Adresse	3 oder mehr Verifizierungssitzungen für 3 oder mehr Personen innerhalb von 48 Stunden.

Die Ansichten berücksichtigen Daten bis zu 31 Tage rückwirkend.

Ereignisregeln

Anmeldeereignisse durchlaufen dieselben Ereignisregeln wie Ihre übrigen Ereignisse. Das Paket Authentication fraud enthält vier Vorlagen:

Vorlage	Trifft zu	Aktionen
Account takeover	Eine Passwort- oder MFA-Änderung nach 3 oder mehr fehlgeschlagenen Anmeldungen und einem neuen Gerät innerhalb von 1 Stunde.	Ablehnen (Score 90), taggen, abmelden, sperren
Credential stuffing	Eine erfolgreiche Anmeldung von einer Adresse mit 10 oder mehr Fehlschlägen bei 3 oder mehr Konten innerhalb von 1 Stunde.	Prüfen (Score 60), taggen, abmelden
Neues Gerät, dann eine Auszahlung	Eine Auszahlung innerhalb von 15 Minuten nach einem neuen Gerät.	Prüfen (Score 60), taggen, abmelden
Impossible travel	Mehr als 500 km zwischen Anmeldungen bei mehr als 1.000 km/h.	Prüfen (Score 50), taggen, abmelden

Nützliche Felder für Ihre eigenen Regeln sind unter anderem 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 und event.ip.travel_speed_kmh. Ereignisregeln haben zwei Aktionen, die nur für Anmeldeereignisse gelten: Die Person von jeder Sitzung abmelden und Die Person für Anmeldungen sperren. Sie sind noch nicht aktiv. Bis dahin protokolliert eine Regel sie mit dem Status DISABLED und wendet sie nicht an. Die übrigen Aktionen (Score, Status, Tags, Notizen, Listen und Fälle) funktionieren wie gewohnt.

Webhooks

Abonnieren Sie ein Webhook-Ziel für die benötigten auth.*-Typen. Nur abonnierte Ziele erhalten sie. Verwenden Sie in der Konsole Try Webhook, um von jedem Typ ein Beispiel zu senden.

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

Deduplizieren Sie anhand von auth_event.event_id, der eigenen ID des Anmeldeereignisses. Sie bleibt bei jeder Zustellung dieses Ereignisses gleich. Über auth_event.event_uuid lesen Sie das gespeicherte Ereignis unter GET /v3/events/{event_uuid}/ aus.
vendor_data, vendor_user_id und authentication sind null für einen Versuch, der keine bekannte Person nennt.
Prüfen Sie die Signatur wie bei jedem Didit-Webhook (siehe Webhooks).

Abrechnung

Authentifizierungsereignisse werden nicht pro Ereignis abgerechnet. Die Authentifizierung wird pro monatlich aktivem Benutzer abgerechnet.

Ereignisse in Ihrer Anwendung

Bei Aktionen in Ihrem eigenen Produkt, etwa einer Profiländerung oder einer Auszahlungsanfrage, übermitteln Sie die Ereignisse selbst: entweder von Ihrem Server aus (POST /v3/events/ mit x-api-key) oder vom Gerät aus mit einem Monitoring-Token mit eingeschränktem Geltungsbereich. Siehe Ereignisse und Ereignisübermittlung über das SDK. Verwenden Sie das vendor_data der Person aus deren Zugriffstoken.

Leitfäden