Zum Hauptinhalt springen
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. 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, die einzelnen Methoden unter Anmeldemethoden.

​
Plattform auswählen

JavaScript

Gehostete Anmeldung, Callback, Sitzung und Abmeldung.

React

Client-Zustand und geschützte Anwendungsansichten.

Next.js

Serverseitige Sitzungen, Callback-Routen und Cookies.

iOS

System-Browser und sichere Token-Speicherung.

Android

Browser-Autorisierung und App-Callbacks.

React Native

Vorbereitung des nativen Authentication-Wrappers.

Flutter

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 (bis zu 50) und die allowed_origins des Browsers (bis zu 50), die die Laufzeit-API aufrufen.
  3. Aktivieren Sie die Anmeldemethoden, 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. 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://<slug>.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.

​
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 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. Leiten Sie vendor_data in Ihrem Backend aus einem verifizierten Token ab, niemals aus einem ungeprüften Browserfeld. Verwenden Sie für jede Kombination den gemeinsamen Integrations-Prompt. Lesen Sie Bot-Schutz für die Richtlinien, die bei der Anmeldung greifen.
Zuletzt geändert am 7. November 2026