Zum Hauptinhalt springen
Die Authentifizierung ist neu: DiditAuth for Android ist releaseabhängig. Distributionsangaben, Versionen und aufrufbare Signaturen sind hier nicht bestätigt. Installieren Sie kein vermutetes Paket und verwenden Sie das Ausweisverifizierungs-SDK nicht als Authentifizierungs-SDK.

​
Anwendung vorbereiten

  1. Bestätigen Sie, dass die Authentifizierung für Ihre Didit-Anwendung aktiviert ist, und kopieren Sie deren Anmelde-Origin (https://<slug>.auth.didit.me bzw. <slug>.sandbox.auth.didit.me für die Sandbox) aus der Konsole.
  2. Registrieren Sie eine exakte Callback-URL, die von Ihrer Anwendung und der Laufzeitumgebung unterstützt wird. Prüfen Sie die Eigentümerschaft der App-Links. Gehen Sie nicht davon aus, dass beliebige benutzerdefinierte URL-Schemata akzeptiert werden.
  3. Halten Sie Sandbox- und Live-Konfiguration getrennt, einschließlich der Callback-Verarbeitung und der gespeicherten Zugangsdaten.
  4. Legen Sie Ihre stabile Personenzuordnung fest, bevor Sie Verifizierung oder Überwachung verbinden.
Verwenden Sie für die gehostete Anmeldung einen System-Browser-Tab und prüfen Sie den zurückkehrenden App-Link. Native Passkeys erfordern die konfigurierte Relying-Party-Domain und den plattformspezifischen Ablauf für Credentials.

​
Gehosteten Ablauf implementieren

Öffnen Sie einen System-Browser-Tab mit der URL {origin}/sign-in. Übergeben Sie einen neuen, zufälligen state, eine S256-PKCE-Challenge und Ihre registrierte redirect_uri. Bewahren Sie den Verifier nur für diesen Versuch in Ihrer App auf. Der JavaScript-Quickstart zeigt das zugrunde liegende Protokoll. Verwenden Sie im nativen Code die Kryptografie und die URL-Verarbeitung der Plattform statt Browser-Globals. Prüfen Sie beim Callback zuerst den state, die Lebensdauer der Transaktion und das Callback-Ziel, bevor Sie den einmalig verwendbaren Code am token/-Endpoint gegen Token eintauschen. Verwenden Sie den ursprünglichen Verifier und die exakte Redirect-URI. Das Abbrechen oder Schließen des Browsers ist keine erfolgreiche Anmeldung. Speichern Sie Refresh-Token ausschließlich in verschlüsseltem, plattformgeschütztem Speicher, niemals in einer einfachen Einstellungsdatei, in Analysedaten oder in Absturzprotokollen. Prüfen Sie die aktuelle Sitzung mit GET session/ und dem Bearer-Token des Endbenutzers. Serialisieren Sie die Token-Erneuerung und ersetzen Sie beide Token gemeinsam. Löschen Sie benutzerspezifischen Zustand nach der Abmeldung. Den Anfragevertrag und das Verhalten bei wiederverwendeten Refresh-Token finden Sie unter Token und JWKS.

​
Vorschau des nativen SDK-Release

Die nativen Authentifizierungsmodule sollen Anmeldung, Zugriff auf die aktuelle Sitzung, Token-Abruf, Abmeldung und Step-up mit automatischen Gerätesignalen bereitstellen. Native Passkeys und geschützter Token-Speicher sind Teil dieses Release. Wrapper-APIs folgen den veröffentlichten Plattformverträgen. Übernehmen Sie keine geratenen Konstruktorargumente oder Methodensignaturen aus einem Designbeispiel. Bis das Modul veröffentlicht ist, deaktivieren Sie dessen Adapter oder verwenden Sie eine geprüfte Implementierung des gehosteten Protokolls für Ihre aktivierte Anwendung. Bewerben Sie keinen funktionierenden nativen Authentifizierungs-Schnellstart, der nur auf der Installation des Pakets beruht.

​
Verifizierung und Überwachung verbinden

Ihr Backend leitet vendor_data aus der authentifizierten Person ab. Es erstellt Verifizierungssitzungen oder erzeugt Monitoring-Token mit beschränktem Geltungsbereich für diese Person. Geben Sie nur den Sitzungsnachweis oder das Token mit beschränktem Geltungsbereich an Ihre App zurück. Der API-Schlüssel bleibt auf dem Server. Verwenden Sie das Android-Verifizierungs-SDK, wenn Sie Ausweisverifizierung benötigen. Für die Unterstützung der Überwachung auf Ihrer Plattform folgen Sie der SDK-Transaktionsübermittlung. Behandeln Sie Anmeldung, Verifizierung und Transaktionsentscheidungen getrennt voneinander.

​
Integration verifizieren

Testen Sie die Rückkehr in eine zuvor beendete App, den Wechsel zwischen Hintergrund und Vordergrund, den Abbruch im Browser, einen nicht passenden Callback, die Wiederverwendung eines Codes, den Ablauf von Token, parallele Erneuerung, MFA, Abmeldung und die Anmeldung als anderer Benutzer. Testen Sie die Passkey-Registrierung und -Anmeldung auf unterstützten Geräten, sobald dieses Release verfügbar ist. Eine reine Geräteprüfung bleibt unverifiziert, bis sie auf der Zielplattform ausgeführt wurde.
Zuletzt geändert am 7. November 2026