> ## 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. # Authentifizierung: Anmeldung, Passkeys und Sitzungen > Mit Didit Endbenutzer anmelden: Passkeys, Codes, Social Login und SSO über gehostete Seiten, verknüpft mit Verifizierung. > [!WARNING] > > Authentication ist neu. Didit aktiviert das Produkt für Ihre Anwendung. Bis dahin liefert jede Laufzeitroute für diese Anwendung `404`. Die Authentication-SDK-Pakete sind noch nicht veröffentlicht. Verwenden Sie daher den gehosteten Ablauf und den HTTP-Vertrag auf diesen Seiten. Authentication meldet Ihre Kundinnen und Kunden bei **Ihrer Anwendung** an. Das ist getrennt von der Anmeldung in der Didit-Konsole und von der Erstellung eines Didit-Entwicklerkontos. Es ist außerdem getrennt von der Identitätsprüfung einer Person. Nutzen Sie Authentication allein oder kombinieren Sie es mit der Ausweisverifizierung und der Transaktionsüberwachung. Eine Anmeldung genehmigt weder eine Verifizierung noch autorisiert sie eine Zahlung. Ihr Backend trifft diese Entscheidungen anhand des Ergebnisses des jeweiligen Produkts. ## So funktioniert es Jede Anwendung erhält einen eigenen Anmelde-Ursprung und einen eigenen Token-Aussteller. Live- und Sandbox-Anwendungen sind getrennt: Sie haben eigene Ursprünge, Einstellungen und Identitäten. | Element | Wert | | - | - | | Standard-Ursprung | `https://.auth.didit.me` für eine Live-Anwendung, `https://.sandbox.auth.didit.me` für eine Sandbox-Anwendung. Die Console zeigt Ihren Ursprung an. Eine verifizierte benutzerdefinierte Domain kann ihn ersetzen. | | Gehostete Seiten | `/sign-in`, `/magic`, `/invite` und `/reset` auf diesem Ursprung. | | Laufzeit-API | Derselbe Ursprung, zum Beispiel `POST {origin}/token/` und `GET {origin}/session/`. | | Aussteller | Der Ursprung selbst. Die Discovery-Informationen liegen unter `{origin}/.well-known/openid-configuration`. | | Veröffentlichbarer Schlüssel | `pk_live_...` oder `pk_test_...`. Er identifiziert die Anwendung und ist kein Geheimnis. | Der Ablauf verwendet den OAuth-2.0-Authorization-Code-Flow mit PKCE (nur `S256`): 1. Ihre App öffnet `{origin}/sign-in` mit `redirect_uri`, `state`, `code_challenge` und `code_challenge_method=S256`. 2. Die gehostete Seite meldet die Person mit den von Ihnen aktivierten Methoden an oder registriert sie, einschließlich eines erforderlichen zweiten Faktors. 3. Der Browser kehrt mit `code` und `state` zu Ihrer `redirect_uri` zurück. 4. Ihre App tauscht den Code bei `POST {origin}/token/` gegen ein Access Token, ein ID Token und ein Refresh Token. Den Token-Vertrag finden Sie unter [Tokens und JWKS](https://docs.didit.me/de/authentication/tokens-and-jwks.md), die einzelnen Methoden unter [Anmeldemethoden](https://docs.didit.me/de/authentication/sign-in-methods.md). ## Plattform auswählen > [card] [JavaScript](https://docs.didit.me/de/authentication/quickstarts/javascript.md) > > Gehostete Anmeldung, Callback, Sitzung und Abmeldung. > [card] [React](https://docs.didit.me/de/authentication/quickstarts/react.md) > > Client-Zustand und geschützte Anwendungsansichten. > [card] [Next.js](https://docs.didit.me/de/authentication/quickstarts/nextjs.md) > > Serverseitige Sitzungen, Callback-Routen und Cookies. > [card] [iOS](https://docs.didit.me/de/authentication/quickstarts/ios.md) > > System-Browser und sichere Token-Speicherung. > [card] [Android](https://docs.didit.me/de/authentication/quickstarts/android.md) > > Browser-Autorisierung und App-Callbacks. > [card] [React Native](https://docs.didit.me/de/authentication/quickstarts/react-native.md) > > Vorbereitung des nativen Authentication-Wrappers. > [card] [Flutter](https://docs.didit.me/de/authentication/quickstarts/flutter.md) > > Vorbereitung des nativen Authentication-Wrappers. ## Anwendung vorbereiten 1. Bitten Sie Didit, Authentication für Ihre Anwendung zu aktivieren. Testen Sie zuerst in einer Sandbox-Anwendung. 2. Registrieren Sie Ihre exakten [Weiterleitungs-URLs](#weiterleitungs-urls) (bis zu 50) und die `allowed_origins` des Browsers (bis zu 50), die die Laufzeit-API aufrufen. 3. Aktivieren Sie die [Anmeldemethoden](https://docs.didit.me/de/authentication/sign-in-methods.md), die Sie anbieten möchten. Didit ID Wallet ist immer aktiv. 4. Wählen Sie Ihre Einstellungen für Sitzungen und Passwörter (siehe unten). 5. Testen Sie Registrierung, Anmeldung, das Zurücksetzen vergessener Passwörter und MFA, Sitzungsablauf und Abmeldung, bevor Sie live gehen. Ein Passkey gehört zu seinem Ursprung. Aktivieren Sie später eine benutzerdefinierte Domain, müssen Personen ihre Passkeys erneut registrieren. ## Weiterleitungs-URLs Didit leitet eine Person nur an eine Adresse weiter, die Sie registriert haben. Registrieren Sie Ihre Adressen in der Console unter **Authentication > Security and sessions > Redirect URLs and allowed origins**. Die `redirect_uri` in einer Anmeldeanfrage muss einer registrierten URL Zeichen für Zeichen entsprechen: Schema, Host, Port, Pfad und Abfrage. Ein anderer Port, ein abschließender Schrägstrich oder eine andere Groß- und Kleinschreibung ergibt eine andere Adresse. | Anwendung | Was Sie registrieren können | | - | - | | Live | `https://`-URLs | | Sandbox | `https://`-URLs sowie `http://`-URLs auf `localhost`, `127.0.0.1` oder `[::1]` | Platzhalter, Fragmente, Zugangsdaten in der URL und benutzerdefinierte Schemata werden abgelehnt. Ist die Adresse nicht registriert, leitet Didit nie dorthin weiter. `{origin}/sign-in` antwortet mit `400` und einer Seite, die erklärt, was Sie wo registrieren müssen. `POST {origin}/authorize/` antwortet mit `400 {"error": "invalid_redirect_uri"}`. ### Lokale Entwicklung Testen Sie auf Ihrem eigenen Rechner mit Ihrer Sandbox-Anwendung: 1. Registrieren Sie Ihren Callback mit seinem Port, zum Beispiel `http://localhost:3000/auth/callback`. 2. Ruft Browser-Code die Laufzeit-API auf, um den Code bei `POST {origin}/token/` gegen die Token einzutauschen, fügen Sie den Ursprung ebenfalls unter **Erlaubte Ursprünge** hinzu: `http://localhost:3000`, ohne Pfad und ohne abschließenden Schrägstrich. 3. Starten Sie die Anmeldung über Ihren Sandbox-Ursprung `https://.sandbox.auth.didit.me` mit Ihrem `pk_test_...`-Schlüssel. `localhost`, `127.0.0.1` und `[::1]` sind getrennte Adressen, und jeder Port ebenfalls. Registrieren Sie jede Adresse, die Sie verwenden. Live-Anwendungen akzeptieren nie `http://`. Registrieren Sie vor dem Go-live Ihren Produktions-Callback mit `https://` in Ihrer Live-Anwendung. ## Anwendungseinstellungen Sie verwalten diese Einstellungen in der Console oder mit einer autorisierten Console-Sitzung, die `write:authentication` besitzt. | Einstellung | Werte | Standard | | - | - | - | | `session_lifetime` | `86400`, `604800`, `2592000`, `7776000` Sekunden | `2592000` (30 Tage) | | `idle_timeout` | `1800`, `7200`, `86400`, `604800` Sekunden | `86400` (1 Tag) | | `multiple_sessions` | `false` meldet die Person bei jeder neuen Anmeldung von ihren anderen Sitzungen ab | `true` | | `password_min_length` | `8`, `10`, `12`, `14` | `10` | | `revoke_on_password_change` | Beendet alle Sitzungen nach einem Passwort-Reset | `true` | | `signup_policy` | `anyone`, `invited`, `allowed_domains` (mit `allowed_email_domains`, bis zu 100) | `anyone` | | `allow_subaddresses` | `+` im lokalen Teil der E-Mail-Adresse akzeptieren | `false` | | `post_logout_redirect_uri` | Wohin Ihre Anwendung die Person nach der Abmeldung weiterleitet | Leer | | `mfa_policy` | `optional`, `everyone`, `organization_admins` | `organization_admins` | | `sign_in_ui` | `hosted` oder `own` | `hosted` | ## Dieselbe Person über alle Produkte hinweg verwenden Jede Identität enthält einen `vendor_data`-Wert. Dabei handelt es sich um die `external_id`, die Sie beim [Import](https://docs.didit.me/de/authentication/migration.md) der Person angegeben haben, andernfalls um die Didit-Identitäts-ID. Er erscheint im Access-Token, im ID-Token und in `GET session/`. Verwenden Sie denselben Wert als `vendor_data`, wenn Sie Verifizierungssitzungen erstellen und Transaktionen einreichen. Authentifizierungsereignisse werden dann in der Console derselben Person zugeordnet wie deren Verifizierungen und Transaktionen. Siehe [Ereignisse und Webhooks](https://docs.didit.me/de/authentication/events-and-webhooks.md). Leiten Sie `vendor_data` in Ihrem Backend aus einem verifizierten Token ab, niemals aus einem ungeprüften Browserfeld. | Produktkombination | Was Sie entwickeln | | - | - | | Authentifizierung | Anmelden, Sitzungen validieren und abmelden. | | Ausweisverifizierung + Authentifizierung | Nach der Anmeldung eine Verifizierung starten, wenn Ihre Richtlinie dies verlangt, mit dem `vendor_data` aus dem Token. | | Transaktionsüberwachung + Authentifizierung | Transaktionen für das `vendor_data` der angemeldeten Person einreichen. Anmeldeereignisse gelangen zur Zeitleiste und zu den Regeln derselben Person. | | Alle drei | Ein `vendor_data` pro Person. Die Entscheidung jedes Produkts gesondert behandeln. | Verwenden Sie für jede Kombination den [gemeinsamen Integrations-Prompt](https://docs.didit.me/de/integration/integration-prompt.md). Lesen Sie [Bot-Schutz](https://docs.didit.me/de/authentication/bot-protection.md) für die Richtlinien, die bei der Anmeldung greifen. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.