Zum Hauptinhalt springen
Ein plattformübergreifendes React-Native-SDK, das die nativen iOS- und Android-SDKs kapselt und eine einheitliche TypeScript-API für die Identitätsverifizierung bereitstellt.

GitHub-Repository

Quellcode und Beispiele auf GitHub ansehen

npm-Paket

@didit-protocol/sdk-react-native

Natives SDK: Dies ist der empfohlene Ansatz für React-Native- und Expo-Apps. Das SDK kapselt die nativen iOS- und Android-SDKs für das bestmögliche Nutzererlebnis, eine optimierte Kamerasteuerung und volle NFC-Unterstützung.


Anforderungen

Plattformanforderungen

Die biometrische Einwilligung erfordert eine native SDK-Version von 4.10.0 oder neuer. Bei Personen, die den Gesetzen von Illinois, Texas oder Colorado unterliegen, kann Didit vor der ersten Gesichtsaufnahme eine ausdrückliche biometrische Einwilligung einholen. Eine React-Native-SDK-Version, die native iOS- und Android-Versionen 4.10.0 oder neuer festlegt, zeigt diesen Schritt an. Frühere Versionen können diesen Schritt nicht anzeigen: Ihre Sitzungen laufen wie bisher weiter, und die Entscheidung meldet die Einwilligung als nicht erfasst (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Aktualisieren Sie, wenn Sie Personen in diesen Bundesstaaten verifizieren.

Installation

Expo (empfohlen)

Fügen Sie anschließend das Konfigurations-Plugin zu Ihrer app.json (oder app.config.js) hinzu. NFC ist standardmäßig aktiviert:
Das Plugin konfiguriert beide Plattformen automatisch:
  • Android: Fügt das Didit-Maven-Repository zu Gradle hinzu, setzt die Gradle-Property diditSdkAndroidNfcEnabled und wendet die Abhängigkeits- und Paketierungsregeln für BouncyCastle an
  • iOS: Fügt das DiditSDK-Podspec zum Podfile hinzu (auf iOS 15 fixiert, wenn NFC aktiviert ist)
Das Plugin bearbeitet Info.plist nicht. Fügen Sie die iOS-Berechtigungsschlüssel hinzu und bei NFC zusätzlich die ISO7816-Select-Identifier unter ios.infoPlist in derselben Datei. D392F000260100000001 ermöglicht dem SDK das Auslesen der Japan My Number Card über JPKI:

NFC-Abhängigkeiten deaktivieren

Um ohne NFC-Unterstützung zu bauen (kleinere Binärdatei, keine NFC-Funktion erforderlich), übergeben Sie Plugin-Optionen:
Wenn NFC deaktiviert ist, benötigen Sie weder die iOS-NFC-Capability, NFC-Berechtigungen noch die NFC-bezogene Bereitstellungskonfiguration.
Dieses SDK verwendet native Module (Kamera, NFC), die in Expo Go nicht verfügbar sind. Sie müssen einen Entwicklungs-Build verwenden oder npx expo prebuild ausführen, um die nativen Projekte zu erzeugen.

React Native CLI

iOS-Einrichtung

Fügen Sie den DiditSDK-Pod zu Ihrem Podfile hinzu (er ist nicht im CocoaPods-Trunk verfügbar). Der folgende Block berücksichtigt die Umgebungsvariable DIDIT_SDK_IOS_NFC_ENABLED, sodass Sie bei der Installation zwischen dem Subspec ohne NFC (DiditSDK/Core) umschalten können:
Der Tag in der Podspec-URL muss mit diditNativeSdkVersions.ios in der installierten Paketversion übereinstimmen. React Native 4.13.2 verwendet das native iOS-SDK 4.13.2 und das native Android-SDK 4.13.2. Verweisen Sie das Podspec nicht auf main: Das Paket hängt von genau dieser nativen iOS-Version ab. Sobald main eine höhere Version enthält, sieht CocoaPods zwei inkompatible Anforderungen für DiditSDK, und jedes pod install schlägt fehl. Das Expo-Konfigurations-Plugin leitet diese URL für Sie ab; nur der reine React-Native-CLI-Pfad muss sie manuell angeben.
Installieren Sie danach die Abhängigkeiten:
Um ohne NFC-Abhängigkeiten neu zu bauen, bereinigen Sie CocoaPods und führen Sie den Befehl mit gesetzter Umgebungsvariable erneut aus:

Android-Einrichtung

Fügen Sie das Didit-Maven-Repository zu Ihrer projektweiten settings.gradle hinzu:
Fügen Sie Folgendes in Ihre android/app/build.gradle ein (innerhalb des Blocks android { ... }), um BouncyCastle-Konflikte durch doppelte Klassen und das doppelte OSGI-MANIFEST.MF aufzulösen, die durch transitive Abhängigkeiten des DiditSDK ausgelöst werden können:
Um ohne Android-NFC-Abhängigkeiten zu bauen (verwendet das Artefakt me.didit:didit-sdk-core statt me.didit:didit-sdk), fügen Sie Folgendes zu android/gradle.properties hinzu:
Entfernen Sie diese Property oder setzen Sie sie auf true, um das vollständige Android-SDK mit NFC zu verwenden.

Berechtigungen

iOS

Fügen Sie die folgenden Schlüssel zur Info.plist Ihrer App hinzu. Fehlen erforderliche iOS-Datenschutzschlüssel, beendet iOS die App, sobald das SDK auf die geschützte Ressource zugreift.

NFC-Konfiguration

So aktivieren Sie das NFC-Auslesen von Reisepässen und Ausweisen mit Chip:
  1. NFC-Capability hinzufügen in Xcode:
    • Wählen Sie Ihr Target > Signing & Capabilities > + Capability > Near Field Communication Tag Reading
  2. ISO7816-Identifikatoren zu Info.plist hinzufügen:
Mit D392F000260100000001 kann das SDK die japanische My Number Card über JPKI lesen: Ohne diesen Identifikator meldet iOS die Karte nicht an das SDK. Das Lesen der My Number Card ist in der Produktion noch nicht aktiviert, und der Identifikator wirkt sich nicht auf andere Dokumente aus, sodass Sie ihn schon jetzt hinzufügen können.
  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. Diese NFC-Konfiguration ist nicht erforderlich, wenn NFC deaktiviert ist.

Android

Die folgenden Berechtigungen sind in der AndroidManifest.xml des SDK deklariert und werden automatisch zusammengeführt: Kamera- und NFC-Hardwarefunktionen sind als optional deklariert (android:required="false"), sodass Ihre App auch auf Geräten ohne diese Funktionen installiert werden kann.

Schnellstart


Integrationsmethoden

Das SDK unterstützt zwei Integrationsmethoden:

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

Erstellen Sie auf Ihrem Backend über die Create Verification Session API eine Sitzung und übergeben Sie dann das Token an das SDK:
Dieser Ansatz gibt Ihnen die volle Kontrolle über:
  • Zuordnung der Sitzungen zu Ihren Benutzern (vendor_data)
  • Festlegen benutzerdefinierter Metadaten
  • Konfiguration der Callbacks pro Sitzung

Methode 2: Workflow-ID (einfachere Integration)

Für einfachere Integrationen kann das SDK Sitzungen direkt mit Ihrer Workflow-ID erstellen:

Konfiguration

Passen Sie das Verhalten des SDK an, indem Sie ein DiditConfig-Objekt übergeben:
Übergeben Sie für startVerificationWithWorkflow die Konfiguration innerhalb von options.config:

Konfigurationsoptionen

Kameraoptionen

Die Kameraoptionen entsprechen den Kameraoptionen des Web SDK. Jedes Objektiv ist CameraLens.Front oder CameraLens.Back. Wenn das Gerät das angeforderte Objektiv nicht hat, verwendet das SDK die erste verfügbare Kamera. Der Kamerawechsler wird auch auf Geräten mit nur einer Kamera ausgeblendet. Setzen Sie eine Option für den Kamerawechsler auf false, damit der Benutzer auf das Standardobjektiv dieses Schritts beschränkt wird.
Design und Farben: Farben, Hintergründe und Einstellungen des Intro-Bildschirms werden über Ihre White-Label-Einstellungen in der Didit Console konfiguriert, nicht in der SDK-Konfiguration. So bleibt das Branding auf allen Plattformen einheitlich.

Unterstützte Sprachen

Das SDK unterstützt 54 Sprachen. Wenn keine Sprache angegeben ist, verwendet das SDK die Gerätesprache und greift als Fallback auf Englisch zurück.
Alle unterstützten Sprachen anzeigen →

Erweiterte Optionen

Diese Optionen sind nur mit startVerificationWithWorkflow verfügbar, bei dem das SDK die Sitzung in Ihrem Auftrag erstellt.

Kontaktdaten (Vorausfüllung & Benachrichtigungen)

Geben Sie Kontaktdaten an, um Verifizierungsformulare vorauszufüllen und E-Mail-Benachrichtigungen zu aktivieren:

Erwartete Angaben (Kreuzvalidierung)

Geben Sie erwartete Benutzerdaten für die automatische Kreuzvalidierung mit den aus dem Dokument extrahierten Daten an:
Alle Felder von ExpectedDetails sind optional. Den vollständigen Typ finden Sie in src/types.ts.

Benutzerdefinierte Metadaten

Speichern Sie benutzerdefinierte JSON-Metadaten mit der Sitzung (werden dem Benutzer nicht angezeigt):

Ergebnisse verarbeiten

Beide Methoden, startVerification und startVerificationWithWorkflow, geben ein Promise<VerificationResult> zurück. Das Ergebnis ist eine diskriminierte Union. Den Ausgang bestimmen Sie über das Feld type.

Ergebnisfälle

SessionData-Eigenschaften

Fehlertypen

Verbindungsverlust

Wenn das Gerät während der Verifizierung die Verbindung verliert, zeigt das SDK einen Bildschirm mit „Keine Internetverbindung“ an, der den Ablauf überlagert, statt einen Schritt weiterhin im Ladezustand zu belassen. Es prüft im Hintergrund weiter und schließt den Bildschirm automatisch, sobald Didit wieder erreichbar ist. Der Benutzer setzt die Verifizierung dann ab dem Schritt fort, an dem er zuletzt war. Der Bildschirm bietet Erneut versuchen und, wenn showCloseButton auf true gesetzt ist (Standardwert), Verifizierung beenden. Beim Beenden endet die Verifizierung mit dem Ergebnis failed, dessen Fehler networkError ist. Ihre App erkennt so, dass der Benutzer wegen der Verbindung abgebrochen hat.

Vollständiges Beispiel zur Ergebnisverarbeitung


End-to-End-Beispiel (Backend-Sitzung → React-Native-SDK → Webhook)

Die produktionsreife Integration funktioniert so: Ihr Backend erstellt die Sitzung, Ihre React-Native-App erhält das session_token, und das SDK führt den Ablauf aus. Die endgültige Entscheidung wird per Webhook an Ihr Backend zugestellt. Vertrauen Sie niemals allein dem clientseitigen Ergebnis.

1. Backend: Sitzung erstellen

2. React Native: Token austauschen und SDK starten

3. Backend: Endgültige Entscheidung per Webhook empfangen

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

Vollständiges Beispiel


Zuletzt geändert am 7. November 2026