Zum Hauptinhalt springen
Ein plattformübergreifendes Flutter-Plugin, das die nativen iOS- und Android-SDKs kapselt und eine einheitliche Dart-API für die Identitätsverifizierung bereitstellt.

GitHub-Repository

Quellcode und Beispiele auf GitHub ansehen

pub.dev-Paket

didit_sdk

Natives SDK: Dies ist der empfohlene Ansatz für Flutter-Apps. Das SDK kapselt die nativen iOS- und Android-SDKs über Plattform-Channels und bietet damit das beste Nutzererlebnis, eine optimierte Kamerasteuerung und volle NFC-Unterstützung.


Anforderungen

Plattformanforderungen

Die biometrische Einwilligung erfordert natives SDK 4.10.0 oder neuer. Für Personen, die unter die Gesetze von Illinois, Texas oder Colorado fallen, kann Didit vor der ersten Gesichtsaufnahme eine ausdrückliche biometrische Einwilligung einholen. Eine Flutter-SDK-Version, die die nativen iOS- und Android-SDKs auf Version 4.10.0 oder höher festlegt, zeigt diesen Schritt an. Ältere Versionen können den Schritt nicht anzeigen: Ihre Sitzungen laufen wie bisher weiter, und die Entscheidung meldet die Einwilligung als nicht erhoben (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Aktualisieren Sie das SDK, wenn Sie Personen in diesen Bundesstaaten verifizieren.

Installation

Alternativ fügen Sie es manuell zu Ihrer pubspec.yaml hinzu:
Führen Sie anschließend aus:

Varianten des nativen SDK

didit_sdk enthält das vollständige native SDK. Um ein kleineres Binary auszuliefern, binden Sie stattdessen ein Varianten-Paket ein. Es stellt exakt dieselbe Dart-API bereit und fixiert auf beiden Plattformen das passende native SDK:
Binden Sie genau eines dieser Pakete ein und importieren Sie aus dem von Ihnen gewählten Paket, zum Beispiel package:didit_sdk_core/sdk_flutter.dart.

iOS-Einrichtung

Das Plugin unterstützt beide iOS-Abhängigkeitsmanager von Flutter: Swift Package Manager und CocoaPods.

Swift Package Manager

Wenn in Ihrer Flutter-Version die Unterstützung für Swift Package Manager aktiviert ist (ab Flutter 3.24+ mit flutter config --enable-swift-package-manager aktivieren), wird das Plugin automatisch als Swift-Paket eingebunden. Eine Podfile-Konfiguration ist nicht nötig. Die native DiditSDK-Abhängigkeit wird automatisch von GitHub aufgelöst. Legen Sie das iOS-Deployment-Target Ihrer App in Xcode (Runner-Target und Projekt) auf das Minimum des gewählten Pakets fest: 15.0 für didit_sdk und didit_sdk_nfc, 13.0 für didit_sdk_core und didit_sdk_autodetection.

CocoaPods

Bei didit_sdk wählt das Plugin die Variante des nativen iOS-SDK über $DiditSdkIosVariant aus, eine globale Ruby-Variable, die Sie in der ios/Podfile Ihrer App setzen (das DiditSDK-Pod ist nicht im CocoaPods-Trunk verfügbar):
Wenn Sie ein Varianten-Paket verwenden (didit_sdk_core, didit_sdk_autodetection, didit_sdk_nfc), fixiert es sein natives Subspec direkt und ignoriert $DiditSdkIosVariant. Halten Sie in diesem Fall die pod-Zeile und das Deployment-Target Ihrer Podfile passend zur Variante (zum Beispiel pod 'DiditSDK/Core', :podspec => ... mit platform :ios, '13.0').
Die Varianten all und nfc erfordern ein Deployment-Target von iOS 15.0+; core und autodetection können auf iOS 13.0 abzielen. Beim Wechseln der Variante bereinigen Sie zuerst CocoaPods (rm -rf Pods Podfile.lock), damit die bisherige SDK-Variante nicht wiederverwendet wird.
Der Tag in der podspec-URL muss mit der nativen iOS-SDK-Version übereinstimmen, die Ihre didit_sdk-Version fixiert (4.13.2 fixiert die native Version 4.13.2). Verweist die URL auf einen älteren Tag, schlägt pod install fehl: CocoaPods findet dann eine podspec, die die ältere Version deklariert, während das Plugin eine exakte Übereinstimmung verlangt. Wenn Sie didit_sdk aktualisieren, setzen Sie den Tag in dieser URL auf dieselbe Version.

Android-Einrichtung

Standardmäßig hängt das Plugin vom vollständigen Android-SDK inklusive NFC ab. Um ohne NFC zu bauen, fügen Sie Folgendes zu android/gradle.properties hinzu:
Dadurch wechselt die Abhängigkeit von me.didit:didit-sdk zu me.didit:didit-sdk-core, und das NFC-Lesemodul sowie seine Abhängigkeiten JMRTD/SCUBA/BouncyCastle entfallen. Wenn NFC aktiviert ist (Standard), fügen Sie diese Packaging-Regel zu android/app/build.gradle.kts hinzu, um eine doppelte Metadatendatei von BouncyCastle aufzulösen:
Ohne diese Regel schlägt der Build mit einem mergeDebugJavaResource-Fehler fehl. Die Regel ist nicht nötig, wenn diditSdkAndroidNfcEnabled=false ist.
Das native Android-SDK wird ab Plugin-Version 3.4.0 aus einem entfernten GitHub-Maven-Repository aufgelöst. Eine manuelle Maven-Konfiguration in Ihrer App ist nicht nötig.

Berechtigungen

iOS

Fügen Sie der Info.plist Ihrer App folgende Schlüssel hinzu:
Fehlt ein erforderlicher iOS-Datenschutzschlüssel, beendet iOS die App, sobald das SDK auf die geschützte Ressource zugreifen möchte. Fehlt beispielsweise NSCameraUsageDescription, stürzt die App ab, wenn der Nutzer die Aufnahmeschaltfläche der Dokumentenkamera antippt.

NFC-Konfiguration

So aktivieren Sie das NFC-Auslesen für Pässe und Ausweise mit Chips:
  1. NFC Capability in Xcode hinzufügen:
    • Wählen Sie Ihr Target > Signing & Capabilities > + Capability > Near Field Communication Tag Reading
  2. ISO7816-Identifier zur Info.plist hinzufügen:
D392F000260100000001 ermöglicht dem SDK das Auslesen der japanischen My Number Card über JPKI. Ohne diesen Identifier meldet iOS die Karte nicht an das SDK. Das Auslesen der My Number Card ist in der Produktion noch nicht aktiviert, und der Identifier wirkt sich nicht auf andere Dokumente aus. Sie können ihn daher bereits jetzt hinzufügen.
  1. Eine Entitlements-Datei hinzufügen, in der das Lesen von NFC-Tags aktiviert ist:
Stellen Sie sicher, dass das Provisioning-Profil der App die Capability NFC Tag Reading enthält. Ist die Bundle-ID in Ihrem Apple-Developer-Konto nicht für NFC konfiguriert, schlägt die Signierung in Xcode mit einem fehlenden com.apple.developer.nfc.readersession.formats-Entitlement fehl. Diese NFC-Konfiguration ist nicht erforderlich für die Varianten core oder autodetection ($DiditSdkIosVariant) oder für die Pakete didit_sdk_core / didit_sdk_autodetection. Keine dieser Varianten bzw. Pakete liest Chips aus.

Android

Die folgenden Berechtigungen sind in der AndroidManifest.xml des SDK deklariert und werden automatisch zusammengeführt: Die Hardware-Funktionen für Kamera und NFC sind als optional deklariert (android:required="false"). Ihre App kann daher auch auf Geräten ohne diese Funktionen installiert werden. Ist diditSdkAndroidNfcEnabled=false gesetzt, fügt das SDK die Android-NFC-Berechtigung und die NFC-Funktion nicht hinzu.

Laufzeitberechtigungen

Das SDK verarbeitet Laufzeitberechtigungsanfragen unter Android automatisch. Erreicht der Nutzer einen Schritt, der Kamerazugriff benötigt:
  1. Fordert das SDK die Kameraberechtigung an, sofern sie noch nicht erteilt wurde.
  2. Verweigert der Nutzer die Berechtigung, wird eine Fehlermeldung mit der Schaltfläche Try Again angezeigt.
  3. Erteilt der Nutzer die Berechtigung, wird der Verifizierungsablauf fortgesetzt.
Sie müssen die Kameraberechtigung im Code Ihrer App nicht anfordern, bevor Sie startVerification() aufrufen. Das SDK übernimmt dies intern.

Schnellstart


Integrationsmethoden

Das SDK unterstützt zwei Integrationsmethoden:

Methode 1: Sitzungs-Token (für die Produktion empfohlen)

Erstellen Sie eine Sitzung in Ihrem Backend über die Create Verification Session API und übergeben Sie das Token dann an das SDK:
Mit diesem Ansatz behalten Sie die volle Kontrolle über:
  • Die Zuordnung von Sitzungen zu Ihren Benutzern (vendor_data)
  • Die Festlegung benutzerdefinierter Metadaten
  • Die Konfiguration von Callbacks pro Sitzung

Methode 2: Workflow-ID (einfachere Integration)

Für einfachere Integrationen kann das SDK Sitzungen direkt mit Ihrer Workflow-ID erstellen. Ein Backend ist dafür nicht erforderlich:
Erweiterte Sitzungsparameter (contact_details, expected_details, metadata) werden nur über die Methode mit Sitzungs-Token unterstützt. Dabei ruft Ihr Backend die Create Session API auf, die alle Parameter vollständig unterstützt. Übergeben Sie das zurückgegebene session_token an DiditSdk.startVerification().

Konfiguration

Passen Sie das Verhalten des SDK an, indem Sie ein DiditConfig-Objekt übergeben:
Für startVerificationWithWorkflow übergeben Sie config als benannten Parameter:

Konfigurationsoptionen

Kameraoptionen

Die Kameraoptionen entsprechen den Kameraoptionen des Web SDK. Jedes Objektiv ist entweder CameraLens.front oder CameraLens.back. Wenn das Gerät nicht über das angeforderte Objektiv verfügt, verwendet das SDK die erste verfügbare Kamera. Der Kameraumschalter wird außerdem auf Geräten mit nur einer Kamera ausgeblendet. Setzen Sie eine Umschalter-Option auf false, damit der Benutzer auf das Standardobjektiv dieses Schritts festgelegt wird.
Gestaltung und Farben: Farben, Hintergründe und Einstellungen des Einführungsbildschirms konfigurieren Sie über Ihre White-Label-Einstellungen in der Didit Console und nicht in der SDK-Konfiguration. So bleibt das Branding auf allen Plattformen einheitlich.

Sprachunterstützung

Das SDK unterstützt 54 Sprachen. Wenn keine Sprache angegeben ist, verwendet das SDK die Gerätesprache, und Englisch dient als Ausweichsprache.
Alle unterstützten Sprachen anzeigen →

Erweiterte Sitzungsparameter

Parameter wie contact_details, expected_details und metadata werden nur über die Sitzungs-Token-Methode unterstützt. Ihr Backend ruft POST /v3/session/ mit voller Parameterunterstützung auf und übergibt anschließend den zurückgegebenen session_token an das SDK.
Die Dart-Methode startVerificationWithWorkflow akzeptiert nur workflowId, vendorData und config. Versionen vor 3.4.0 stellten die Parameter contactDetails, expectedDetails und metadata bereit. Diese wurden entfernt, weil der Unilink-Endpoint sie nicht berücksichtigt.

Ergebnisse verarbeiten

Sowohl startVerification als auch startVerificationWithWorkflow geben ein Future<VerificationResult> zurück. Das Ergebnis ist eine versiegelte Klasse (sealed class). Verwenden Sie Pattern Matching, um das Ergebnis zu bestimmen.

Ergebnisfälle

SessionData-Eigenschaften

Fehlertypen

Die Enum VerificationErrorType stellt die folgenden Fälle bereit:

Verbindungsverlust

Wenn das Gerät während der Verifizierung die Verbindung verliert, blendet das SDK einen Bildschirm mit der Meldung „No internet connection“ über dem Ablauf ein, anstatt einen Schritt im Ladezustand hängen zu lassen. Das SDK prüft im Hintergrund weiter die Verbindung und schließt den Bildschirm automatisch, sobald Didit wieder erreichbar ist. Der Benutzer macht dann an dem Schritt weiter, an dem er zuvor war. Der Bildschirm bietet Try Again und, sofern die Schließen-Schaltfläche nicht deaktiviert ist, Exit Verification. Beim Verlassen endet die Verifizierung mit einem VerificationFailed-Ergebnis, dessen Fehlertyp networkError ist. So erkennt Ihre App, dass der Benutzer den Ablauf aufgrund des Verbindungsverlusts verlassen hat.

Vollständiges Beispiel zur Ergebnisverarbeitung


End-to-End-Beispiel (Backend-Sitzung → Flutter SDK → Webhook)

Dies ist die produktionsreife Integration: Ihr Backend erstellt die Sitzung, Ihre Flutter-App empfängt den session_token, und das SDK führt den Ablauf aus. Die endgültige Entscheidung wird per Webhook an Ihr Backend übermittelt. Vertrauen Sie niemals allein dem clientseitigen Ergebnis.

1. Backend: Session erstellen

2. Flutter: Sitzungs-Token austauschen und SDK starten

3. Backend: endgültige Entscheidung per Webhook empfangen

Details zur HMAC-Signaturprüfung finden Sie im Webhooks-Leitfaden.

Vollständiges Beispiel


Zuletzt geändert am 7. November 2026