> ## 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. # iOS-Schnellstart: Biometrische Authentifizierung > iOS-Integration vorbereiten: gehostete Anmeldung, Callback-Validierung, sichere Sitzungen sowie Links zu Verifizierung und laufender Überwachung mit Didit. > [!WARNING] > > Authentication ist neu: **DiditAuth für iOS** hängt von der jeweiligen Version ab. Distributionsangaben, Versionen und aufrufbare Signaturen sind hier nicht bestätigt. Installieren Sie kein vermutetes Paket und verwenden Sie das Ausweisverifizierungs-SDK nicht als Authentication-SDK. ## Vorbereitung der Anwendung 1. Vergewissern Sie sich, dass Authentication für Ihre Didit-Anwendung aktiviert ist, und kopieren Sie den Anmelde-Origin (`https://.auth.didit.me` bzw. `.sandbox.auth.didit.me` für Sandbox) aus der Konsole. 2. Registrieren Sie eine genaue Callback-URL, die Ihre Anwendung und die Laufzeitumgebung unterstützen. 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 Verarbeitung von Callbacks und der gespeicherten Zugangsdaten. 4. Legen Sie Ihre stabile Zuordnung von Personen fest, bevor Sie Verifizierung oder Monitoring verbinden. Verwenden Sie für die gehostete Anmeldung die systemeigene Authentifizierungssitzung. Planen Sie die native Passkey-Verarbeitung und die Relying-Party-Domain gemeinsam. Eine WebView ist kein Ersatz für den systemseitigen Authentifizierungsablauf. ## Implementierung des gehosteten Ablaufs Öffnen Sie eine systemeigene Authentifizierungssitzung im Browser mit der URL `{origin}/sign-in`. Übergeben Sie einen frischen Zufallswert für `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](https://docs.didit.me/de/authentication/quickstarts/javascript.md) zeigt das zugrunde liegende Protokoll. Verwenden Sie in nativem Code plattformeigene Kryptografie und URL-Verarbeitung statt Browser-Globals. Prüfen Sie beim Callback den state, die Gültigkeitsdauer der Transaktion und das Ziel des Callbacks, bevor Sie den nur einmal verwendbaren Code am `token/`-Endpunkt einlösen. 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-Tokens nur im plattformgeschützten Speicher für Zugangsdaten, niemals in einer einfachen Einstellungsdatei, in Analytics-Systemen oder in Absturzprotokollen. Prüfen Sie die aktuelle Sitzung mit `GET session/` und dem Bearer-Token des Endbenutzers. Serialisieren Sie die Token-Erneuerung, ersetzen Sie beide Tokens gemeinsam und löschen Sie benutzerspezifische Zustände nach der Abmeldung. Den Anfragevertrag sowie das Verhalten bei wiederverwendeten Refresh-Tokens finden Sie unter [Tokens und JWKS](https://docs.didit.me/de/authentication/tokens-and-jwks.md). ## Vorschau der nativen SDK-Version Die nativen Authentication-Module sollen Anmeldung, Zugriff auf die aktuelle Sitzung, Abruf von Tokens, Abmeldung und Step-up-Authentifizierung mit automatischen Gerätesignalen bereitstellen. Native Passkeys und geschützter Token-Speicher sind Teil dieser Version. Wrapper-APIs folgen ihren veröffentlichten Plattformverträgen. Übernehmen Sie keine vermuteten 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 Authentication-Quickstart allein auf Grundlage der Paketinstallation. ## Verifizierung und Monitoring verbinden Ihr Backend leitet `vendor_data` von der authentifizierten Person ab. Es erstellt Verifizierungssitzungen oder stellt auf diese Person beschränkte Monitoring-Tokens aus. Geben Sie an Ihre App nur die Sitzungsanmeldedaten oder das eingeschränkte Token zurück. Der API-Schlüssel bleibt auf dem Server. Verwenden Sie das [iOS-Verifizierungs-SDK](https://docs.didit.me/de/integration/native-sdks/ios-sdk.md), wenn Sie Ausweisverifizierung benötigen. Befolgen Sie [die Anleitung zur SDK-Transaktionsübermittlung](https://docs.didit.me/de/transaction-monitoring/sdk-transaction-submission.md) zur Unterstützung des Monitorings auf Ihrer Plattform. Behandeln Sie Anmeldung, Verifizierung und Transaktionsentscheidungen getrennt voneinander. ## Integration prüfen Testen Sie die Rückkehr zu einer kalt gestarteten App, den Wechsel zwischen Hintergrund und Vordergrund, den Abbruch im Browser, einen nicht übereinstimmenden Callback, die Wiederverwendung eines Codes, den Ablauf von Tokens, gleichzeitiges Erneuern, MFA, die Abmeldung und die Anmeldung als anderer Benutzer. Testen Sie die Registrierung und Anmeldung mit Passkeys auf unterstützten Geräten, sobald diese Version verfügbar ist. Eine reine Geräteprüfung bleibt unbestätigt, bis sie auf der Zielplattform ausgeführt wurde. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.