> ## 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. # Authentifizierungsereignisse und Webhooks > Didit zeigt Anmeldeaktivitäten in der Konsole: Anmelde-Übersicht und Zeitleiste der Person, Betrugsansichten, Ereignisregeln und auth.*-Webhooks. > [!WARNING] > > 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/`](https://docs.didit.me/de/transaction-monitoring/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](https://docs.didit.me/de/authentication/bot-protection.md)-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/`](https://docs.didit.me/de/management-api/users/list) als `authentication` zurückgegeben: ```json theme={null} { "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](https://docs.didit.me/de/transaction-monitoring/event-rules.md) 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](https://docs.didit.me/de/integration/webhooks.md) 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. ```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" } } ``` * 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](https://docs.didit.me/de/integration/webhooks.md)). ## 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](https://docs.didit.me/de/transaction-monitoring/events.md) und [Ereignisübermittlung über das SDK](https://docs.didit.me/de/transaction-monitoring/sdk-event-submission.md). Verwenden Sie das `vendor_data` der Person aus deren Zugriffstoken. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.