Reibungslose Authentifizierung unter iOS: Unauffällige Netzwerküberprüfung mit Vonage Verify

In diesem Tutorial lernst du, eine reibungslose Authentifizierung unter iOS erstellen: ein „ogin“, das eine Telefonnummer ohne jegliche Benutzereingabe verifiziert, sowie eine Dev-Mode-Konsole, die jeden unsichtbaren Schritt in Echtzeit anzeigt. 

Kurz gesagt

Stille Netzwerkauthentifizierung verifies a phone number without sending a SMS one-time code. Instead, your backend starts a Vonage Verify v2-Workflow, und Ihre iOS-App folgt einem check_url über Mobilfunkdaten, und der Mobilfunkanbieter bestätigt, dass die SIM-Karte im Gerät mit der zu verifizierenden Telefonnummer übereinstimmt.

Die Beispiel-App für diesen Beitrag ist eine SwiftUI-Anmeldung, die von einem kleinen Node.js-Server unterstützt wird. Zunächst wird „Silent Auth“ ausgeführt, SMS und Voice-Anrufe stehen als Fallback-Optionen zur Verfügung, und eine Dev-Mode-Konsole zeigt die API-Aufrufe, Webhooks, Mobilfunkanfragen, den Fallback-Status und die abschließende Zusammenfassung in Echtzeit an.

>> Kurzfassung: Springe direkt zum Schnellstart und den App-Code auf GitHub. 

Nutzer hassen Einmal-Passwörter

Sie warten auf die SMS oder den Anruf. Sie wechseln zwischen Apps hin und her. Sie geben den Code falsch ein. Und vielleicht fallen einige von ihnen einem Phishing-Angriff zum Opfer.

Die Branche reagiert bereits mit Taten: Der „A2P Messaging Market Report 2025“ von Juniper Research prognostiziert, dass das inländische SMS-Aufkommen jährlich um 15 % zurückgehen wird (wobei OTPs etwa 40 % davon ausmachen) und das internationale SMS-Aufkommen jährlich um 23 % sinken wird, da Anwendungsfälle zur Authentifizierung auf Kanäle mit geringeren Reibungsverlusten verlagert werden. (Quelle: Juniper Research, „A2P & Business Messaging Market Report 2025–30“, https://www.juniperresearch.com/research/telecoms-connectivity/messaging/a2p-research-report/)

Die „Silent Authentication“ behebt dieses Problem: Die Telefonnummer wird vom Netzbetreiber selbst anhand der bereits im Gerät eingesteckten SIM-Karte Verified. Das bedeutet, dass weder ein SMS-Code noch irgendeine Aktion seitens des Nutzers erforderlich ist. Der Nutzer tippt einfach auf „Anmelden“ und ist nach der Verification sofort angemeldet. 

Aber hier ist der Haken: Der gesamte Ablauf ist unsichtbar, es wirkt wie Zauberei. Wenn es funktioniert, sieht man nichts. Wenn es fehlschlägt, sieht man ebenfalls nichts. Ist die Netzabdeckungsprüfung fehlgeschlagen? Hat das Gerät statt Mobilfunk auf WLAN umgeschaltet? Hat der Netzbetreiber die Verbindung abgelehnt? Wurde die Fallback-SMS ausgelöst? Man debuggt eine Blackbox. 

Diese Demo-App deckt also den Inhalt dieser „Black Box“ auf. Es handelt sich um einen SwiftUI-Anmeldebildschirm, der auf der Vonage Verify v2-API, wobei „Silent Auth“ als primärer Authentifizierungsfaktor dient und automatische SMS- sowie Voice-Fallback-Optionen zur Verfügung stehen. Außerdem verfügt sie über einen Dev-Modus, der Ihnen hilft zu verstehen, wie „Silent Auth“ wirklich funktioniert. Bei aktiviertem Dev-Modus zeigt die App eine Live-Zeitleiste an, in der alle API-Aufrufe des Servers, alle von Vonage übermittelten Webhooks und alle vom Gerät ausgelösten Mobilfunkanfragen zusammengeführt werden. Alles ist nach Kanälen gruppiert und wird durch leicht verständliche Erläuterungen zu jedem Schritt ergänzt. 

 Dieser Beitrag ist teils eine Kurzanleitung, teils ein Tutorial. Du erfährst, wie man die App ausführt, wie die „Silent Network Authentication“ unter iOS funktioniert und was ich dabei gelernt habe, einen unsichtbaren Authentifizierungsablauf so sichtbar zu machen, dass er sich debuggen lässt.

A short walkthrough of the sample app showing Silent Auth in action, from phone number sign-in to the Dev Mode timeline and final verified state.

Voraussetzungen

Bevor Sie beginnen, vergewissern Sie sich, dass Sie alles haben:

• macOS mit Xcode 15+ 

• Node.js 20+ 

• ngrok oder einen anderen Tunnel, um Ihr lokales Backend für Vonage-Webhooks zugänglich zu machen 

• Ein iPhone mit einer SIM-Karte und Mobilfunkdaten für den echten „Silent Auth“-Pfad 

• Ein Simulator oder ein Testgerät, wenn Sie nur den Ablauf eines virtuellen Betreibers durchspielen möchten

Außerdem benötigen Sie eine Vonage-Application, bei der die Funktionen „Verify“ und „Network Registry“ aktiviert sind. „Network Registry“ ermöglicht die stille Authentifizierung. Die README im Repo erklärt Schritt für Schritt, wie man eine solche erstellt. 

Stille Netzwerkauthentifizierung: Was passiert eigentlich hinter den Kulissen?

Ein Nutzer gibt seine Telefonnummer ein und tippt auf „Anmelden“.

Bei einem normalen SMS-OTP-Ablauf beginnt ein lästiger Vorgang, den wir alle kennen: auf die Nachricht warten, die App verlassen, den Code kopieren oder sich merken, zurückkehren, einfügen, absenden und hoffen, dass es geklappt hat. 

 Bei einem „Silent Network“-Authentifizierungsablauf sieht der Benutzer einen Ladekreis. Wenige Sekunden später ist die Authentifizierung abgeschlossen und der Benutzer wird Verified. 

 Hinter den Kulissen sind zwei Dinge passiert: 

1. Ihr Backend hat eine Vonage Verify v2-Anfrage mit „silent_auth“ als erstem Workflow-Kanal. 

2. Ihre iOS-App hat die zurückgegebene check_url über die Mobilfunkverbindung abgerufen, sodass der Netzbetreiber die Zuordnung von SIM-Karte und Rufnummer direkt über die Netzwerkverbindung selbst bestätigen konnte.  

Der zweite Schritt ist der entscheidende. Das Gerät – nicht Ihr Server – muss die check_urlausführen, und zwar über Mobilfunkdaten. Wenn die Anfrage über WLAN erfolgt, kann der Mobilfunkanbieter den Mobilfunkvertrag nicht anhand des Netzwerkpfads identifizieren. (WLAN-Funktionen werden mit „Silent Auth Advanced“, das sich derzeit in der Alpha-Phase befindet) 

Das ist der gesamte Mechanismus. Das Mobilfunknetz identifiziert die SIM-Karte anhand der Verbindung, genauso wie es erkennt, welchem Handy die Rechnung zu stellen ist. Wenn die SIM-Karte mit der zu überprüfenden Nummer übereinstimmt, enthält die Antwort einen Code, die App sendet diesen Code an Ihr Backend, und das Backend schließt die Verifizierung ab.

„Silent Auth“ ist Teil des umfassenderen Ökosystems der Nummernüberprüfung / Netzwerk-APIs. Aus Sicht eines iOS-Entwicklers ist die praktische Umsetzung jedoch einfacher: 

• Starten Sie eine Verify-Anfrage in Ihrem Backend 

• eine request_id und möglicherweise eine check_url 

• die „check_url“ Anfrage über Mobilfunk aus der iOS-App heraus 

• Sende den zurückgegebenen Code an dein Backend zurück 

• auf SMS oder Voice-Anrufe ausweichen, wenn der lautlose Weg nicht funktioniert 

Die Beispiel-App veranschaulicht diesen Ablauf. 

Was „Silent Authentication“ ist und was sie nicht ist

Die „Silent Authentication“ ist ein SIM-gebundenes Verfahren zur Überprüfung von Telefonnummern. Der Netzbetreiber bestätigt, dass die Telefonnummer zu dem Gerät gehört, von dem die Anfrage stammt. Der Nutzer muss keinen Code eingeben, und es wird keine SMS versendet, die ein Angreifer abfangen oder weiterleiten könnte.

Dies ist sinnvoll, wenn Sie eine Telefonnummernüberprüfung wünschen, die weniger aufwendig ist als ein Einmalpasswort (OTP). Sie kann Teil der Registrierung, der Anmeldung, der erweiterten Authentifizierung, der Kontowiederherstellung oder des Schutzes vor Kontoübernahme sein. Sie ist jedoch kein universeller Ersatz für jeden Authentifizierungsfaktor.

Es handelt sich nicht um einen Passkey. Passkeys sind gerätegebundene Anmeldedaten. „Silent Auth“ ist SIM-gebunden. 

Es handelt sich nicht um Biometrie. Face ID und Touch ID bestätigen, dass ein lokaler Nutzer eine Geräteüberprüfung bestanden hat. Silent Auth bestätigt, dass die aktuelle Geräteverbindung mit der SIM-Karte der Telefonnummer verknüpft ist.

Es handelt sich nicht um ein SMS-OTP. Bei einem SMS-OTP wird ein Code über einen Nachrichtenkanal gesendet. Bei der „Silent Auth“-Methode wird der Mobilfunkanbieter gebeten, die Zuordnung zwischen Gerät und Nummer ohne Eingabe seitens des Nutzers zu bestätigen.

Das beste mentale Modell lautet: „Silent Auth“ Verifies den Besitz einer Telefonnummer mit weniger Aufwand für den Nutzer als per SMS oder Telefonanruf. In einem modernen Authentifizierungs-Stack kann es neben Passkeys, biometrischen Daten, App-Sitzungen, SIM-Swap-Prüfungen und anderen Risikosignalen zum Einsatz kommen. 

Standard- vs. erweiterte stille Authentifizierung

Silent Authentication Advanced ist eine Technologie zur passwortlosen Benutzerauthentifizierung, die die hardwaregestützten kryptografischen Funktionen der SIM-Karte nutzt. Sie befindet sich derzeit in der Alpha-Phase. 
 

Das Fazit für die Praxis: Entwickeln Sie Ihre App hinter einem kleinen „PhoneVerificationService“ auf. Derzeit kann dieser Dienst die Standard- check_url ausführen. Später kann er die „Advanced“-Unterstützung hinzufügen, ohne dass jeder Anmeldebildschirm neu geschrieben werden muss.

protocol PhoneVerificationService {
    func startVerification(
        phoneNumber: String
    ) async throws -> VerificationStartResult

    func completeSilentAuth(
        requestId: String,
        checkURL: URL
    ) async throws

    func checkCode(
        requestId: String,
        code: String
    ) async throws
}

So funktioniert das System

Folgendes passiert, wenn ein Benutzer darauf tippt „Anmelden“antippt: 

1. Die App sendet die Telefonnummer im E.164-Format an Ihr Backend, zum Beispiel 12025550123. 

2. Das Backend ruft „Verify v2“ mit folgendem Workflow auf: [silent_auth, SMS, Voice]. 

3. „Silent Auth“ muss an erster Stelle stehen. Es kann nicht als Ausweichlösung nach SMS verwendet werden. 

4. Vonage gibt eine request_id und, falls die Abdeckungsprüfung erfolgreich war, eine check_url. 

5. Die App ruft die check_url über die Mobilfunkschnittstelle mithilfe der iOS-Client-Bibliothek von Vonage ab, selbst wenn das Telefon zusätzlich mit einem WLAN verbunden ist. 

6. Die Antwort enthält einen Code. 

7. Die App übermittelt die request_id und den Code an das Backend. 

8. Das Backend ruft „Verify v2“ auf, um den Code zu überprüfen. 

9. Sollte dabei etwas schiefgehen (kein check_url, Mobilfunk nicht verfügbar, Ablehnung durch den Netzbetreiber, Zeitüberschreitung), greift der Workflow auf SMS zurück. 

10. Wenn auch die SMS unbeantwortet bleibt, greift Vonage erneut auf eine andere Lösung zurück und ruft den Nutzer an, um ihm einen gesprochenen Code mitzuteilen.

Dabei wird bei jedem dieser Schritte ein strukturiertes Protokollereignis an einen anfragebezogenen Puffer auf dem Server gesendet. Die App fragt diesen Puffer alle 1,5 Sekunden ab und führt die Ereignisse des Servers mit den eigenen geräteseitigen Ereignissen zu einer Zeitachse zusammen.

Das wird im Dev-Modus angezeigt. 

Silent Auth starts on the backend, but the key verification step happens on the device: the iOS app must fetch the check_url over cellular so the carrier can confirm the SIM-to-number match.

Wie es zusammengesetzt ist

1. Der Server

Der Verzeichnis „server/“ Verzeichnis enthält eine kleine Express-App, die alle Vonage-Anmeldedaten und API-Aufrufe verwaltet.

Es stellt vier Endpunkte bereit, die für die App von Bedeutung sind:

1. Eine Überprüfung starten

2. den Arbeitsablauf vorantreiben 

3. einen Code überprüfen 

4. Protokolle abrufen

Außerdem stellt es eine /callback Route für Vonage-Webhooks bereit.

Der Server authentifiziert sich bei Verify v2 mit einer Anwendungs-ID und einem JWT mit privatem Schlüssel. Verify v2 verwendet für diesen Ablauf nicht das klassische Paar aus API-Schlüssel und API-Geheimnis. Es ist wichtig, diese Authentifizierung auf dem Backend zu belassen: Die iOS-App sollte niemals Ihre Vonage-Anmeldedaten oder Ihren privaten Schlüssel enthalten. 

Auf dem Server läuft außerdem ein Channel-Timeout-Mirroraus, was sich als einer der wichtigsten Bestandteile der Demo herausstellte. Mehr dazu im Abschnitt zum Debugging. 

2. Die iOS-App

Die Verzeichnis „ios/“ Verzeichnis enthält eine SwiftUI-App für iOS 16+. 

Der Verifizierungsablauf wird als Zustandsmaschine vom Werttyp modelliert: eine Enumeration, deren Fälle die request_id als zugehörige Daten enthalten. Das bedeutet, dass der Zustand selbst den Anforderungskontext enthält.

Die App kann beispielsweise folgende Zustände durchlaufen: 

• im Leerlauf 

• Beginn 

• awaitingSilentAuth(requestId: ...) 

• enteringSmsCode(requestId: ...) 

• enteringVoiceCode(requestId: ...) 

• verifiziert 

• fehlgeschlagen  

Die Mobilfunkanfrage verwendet VGCellularRequestClient aus der Vonage-iOS-Client-Bibliothek. Dieser Client ermöglicht es der App, die Funktion „check_url“ -Anfrage über die Mobilfunkverbindung zu erzwingen, selbst wenn WLAN aktiv ist. 

3. Datensicherheit

Alles, was auf einem Screenshot zu sehen sein könnte, wird bereits beim Schreiben und nicht erst bei der Anzeige unkenntlich gemacht.

Telefonnummern werden wie folgt angezeigt: +14•••••1234angezeigt, wobei nur die letzten vier Ziffern beibehalten werden. Es werden immer nur die letzten beiden Ziffern der Codes protokolliert – dies reicht aus, um zu belegen, dass der Ablauf funktioniert hat, ist für einen Angreifer jedoch nutzlos. 

Da die Schwärzung bereits bei der Erstellung des Protokollereignisses erfolgt, sind Exporte und Bildschirmaufzeichnungen standardmäßig sicher. Dies ist wichtig, da die Dev-Mode-Konsole für die Weitergabe in Demos, Blog-Screenshots und Fehlerberichten vorgesehen ist. 

Der iOS-Client, der den „Silent Check“ abschließt

Der Kern der iOS-Implementierung ist klein: 

1. Sende die Telefonnummer an dein Backend. 

2. Empfangen request_id und check_url. 

3. Verwenden Sie die Vonage-iOS-Client-Bibliothek, um die check_url über das Mobilfunknetz abzurufen. 

4. Den zurückgegebenen Code auswerten. 

5. Senden Sie den Code zurück an Ihr Backend. 

In der Produktion sollten Sie außerdem prüfen, ob eine Mobilfunkverbindung verfügbar ist, bevor Sie „Silent Auth“ versuchen. Wenn der Benutzer ein iPad ohne Mobilfunkverbindung oder ein Gerät mit deaktivierten mobilen Daten nutzt, können Sie den „Silent“-Pfad überspringen und sofort den SMS-Fallback anzeigen. 

Ein einfaches NWPathMonitor Vorabprüfung kann Ihnen helfen, einen verwirrenden Fehlerzustand zu vermeiden: 

import Combine
import Network

final class ConnectivityMonitor: ObservableObject {
    @Published private(set) var hasCellular = false

    private let monitor = NWPathMonitor()
    private let queue = DispatchQueue(label: "ConnectivityMonitor")

    init() {
        monitor.pathUpdateHandler = { [weak self] path in
            DispatchQueue.main.async {
                self?.hasCellular = path.usesInterfaceType(.cellular)
            }
        }

        monitor.start(queue: queue)
    }

    deinit {
        monitor.cancel()
    }
}

Diese Vorabprüfung ersetzt nicht die Fallback-Behandlung. Sie verbessert lediglich die Benutzererfahrung. Sie müssen weiterhin Fälle von fehlender Netzabdeckung, abgelehnten Schecks, abgelaufenen Anfragen und Zeitüberschreitungen behandeln. 

 Ein Detail, das leicht übersehen wird, ist, dass „Standard Silent Auth“ nur funktioniert, wenn die Anfrage das Gerät über das Mobilfunknetz verlässt. Der Ablauf kann wie eine normale URL-Anfrage aussehen, aber wenn das Gerät die Anfrage über WLAN sendet, kann „Silent Auth“ den Nutzer nicht über das Mobilfunknetz Verify.

The sample app starts as a normal phone-number login screen, but enabling Dev Mode lets you watch the Silent Auth, SMS, and voice workflow after sign-in.

In 10 Minuten ausführen

Schritt 1: Erstellen Sie die Vonage-Application

Im Vonage-Dashboardeine Anwendung erstellen und Verify sowie Netzwerkregistrierung, generieren Sie ein Schlüsselpaar und speichern Sie private.key auf dem server/. Die Datei wird in der Beispiel-App von Git ignoriert.

Für Produktionsumgebungen gilt das Seite mit den Best Practices für „Verify v2 Silent Authentication“ sollten Sie sich durchlesen, sobald Sie die Demo zum Laufen gebracht haben. 

Schritt 2: Starten Sie das Backend

cd server 
cp .env.example .env   # fill in VONAGE_APPLICATION_ID 
npm install 
npm run dev 

Die App geht davon aus, dass Ihr Backend die Verify API-Aufrufe übernimmt. Dies ist die richtige Aufgabenteilung für die Integration einer API zur Telefonverifizierung: Der mobile Client übernimmt die Benutzerinteraktion und die Weiterleitung über das Mobilfunknetz, während das Backend sich um Anmeldedaten, die Erstellung von Workflows, Webhooks und Code-Prüfungen kümmert. 

Schritt 3: Für Webhooks freigeben

ngrok http 4000

Fügen Sie die HTTPS-URL wie folgt in das Feld „Verify-Callback-URL“ Ihrer Vonage-Application ein: 

 https://<your-ngrok-id>.ngrok.io/callback 

Schritt 4: Die App ausführen

Öffnen ios/SilentAuthDemo.xcodeproj, kopieren Sie ios/Config.xcconfig nach ios/Config.local.xcconfig, setzen Sie BASE_URL auf Ihre ngrok-URL ein und drücken Sie Cmd+R. 

Führen Sie Ihre erste Überprüfung durch

Aktivieren Sie den Schalter „Entwicklermodus“ auf dem Anmeldebildschirm, geben Sie eine Zahl ein und tippen Sie auf „Anmelden“.

Die Konsole übernimmt die Bildschirmdarstellung und kommentiert den Ablauf live. 

Was Sie sehen werden

• Ein oben angehefteter Channel-Tracker (SILENT AUTH SMS VOICE), der sich bei jedem Test eines Kanals automatisch ausfüllt: Der aktive Kanal wird hervorgehoben, fehlgeschlagene Kanäle durchgestrichen und der erfolgreiche Kanal markiert.

• Nach Phasen gruppierte Ereignisse, jeweils mit einer Erläuterung in leicht verständlichem Deutsch ganz oben und der maschinengenerierten Bezeichnung darunter.

• Quell-Badges, die zwischen den Aktionen des Servers und denen des Geräts unterscheiden.

• Der zusammenfassende Webhook am Ende – der ist insgeheim der beste Lernmoment im gesamten Ablauf.

Bei erfolgreicher „Silent Auth“-Authentifizierung lautet die abschließende Zusammenfassung in etwa wie folgt:

silent_auth: completed 
sms: unused 
voice: unused 

Die unbenutzten Einträge sind alle Codes, die Ihr Benutzer nicht eingeben musste.

Dev Mode shows the happy path for Silent Auth: the app receives a check_url, performs the cellular check, and verifies the user without any SMS or voice code.

Testen ohne echte SIM-Karte

Man muss kein echtes SMS-Guthaben verbrauchen und nicht einmal eine echte SIM-Karte verwenden, um den Großteil des Ablaufs zu testen.

 Vonages „Network Registry Playground“ von Vanage enthält einen virtuellen Betreiber. Dieser leitet jede Nummer weiter, die mit 990 an einen simulierten Telefonisten weiter und die letzte Ziffer bestimmt das Ergebnis:

 Also 99012345670 zeigt den „Happy Path“ auf einem Simulator, und 99012345671 demonstriert die Fallback-Kaskade.

Ein wichtiger Hinweis: Wenn Sie den virtuellen Operator zuvor mit der alten sandbox:true verwendet haben, sollten Sie keinen neuen Code darauf aufbauen. Der aktuelle Playground-/Virtual-Operator-Ablauf hat diesen Ansatz ersetzt.

Das Einzige, was der Playground nicht simulieren kann, ist die echte Mobilfunkverbindung auf dem Gerät. Dafür benötigen Sie ein echtes iPhone mit Mobilfunkverbindung bei einem unterstützten Anbieter.

Fallback-Fälle behandeln, ohne dass die Benutzeroberfläche seltsam wirkt

„Silent Auth“ sollte nicht Ihre einzige Option sein.

Die Verfügbarkeit variiert je nach Land, Mobilfunkanbieter, Account-Typ, Gerätestatus und Netzwerkstatus. Ein Nutzer ist möglicherweise ausschließlich über WLAN verbunden. Die Mobilfunkverbindung ist möglicherweise deaktiviert. Der Mobilfunkanbieter unterstützt die Nummer möglicherweise nicht. Die Überprüfung kann aufgrund einer Zeitüberschreitung fehlschlagen.

Deshalb startet das Backend den Workflow zunächst mit „Silent Auth“, gefolgt von SMS und Voice:

{
  "brand": "SilentAuthDemo",
  "workflow": [
    { "channel": "silent_auth", "to": "+12025550123" },
    { "channel": "sms", "to": "+12025550123" },
    { "channel": "voice", "to": "+12025550123" }
  ]
}

Die Benutzererfahrung sollte sich an den jeweiligen Kanal anpassen: 

• Wenn die stille Authentifizierung erfolgreich ist, zeige den Erfolgszustand an.

• Falls die stille Authentifizierung fehlschlägt und SMS gestartet wird, zeige die Benutzeroberfläche für den SMS-Code an.

• Wenn die SMS-Zeitüberschreitung eintritt und der Voice-Anruf beginnt, zeige die Benutzeroberfläche für den Voice-Code an.

  Dev Mode shows the fallback path clearly: the cellular Silent Auth check fails, the backend advances the workflow, and the user is verified through SMS instead.

Erkenntnisse aus der Entwicklung der Demo

Diese App wurde mit Claude Code erstellt, basierend auf einer AGENTS.md aus, in der der Arbeitsablauf festgehalten war: Zunächst jede Aufgabe in eine Checkliste eintragen, vor der Fertigstellung Tests schreiben und für diesen Blogbeitrag „blogwürdige Notizen“ hinzufügen.

1. Gerüstbau gegen den Willen der Ärzte

Das erste Risiko bei der KI-gestützten Codierung auf einer sich schnell entwickelnden API sind veraltete Trainingsdaten, und Silent Auth hat sich kürzlich weiterentwickelt. Daher war es entscheidend, die Documentation MCP Server zu nutzen, um auf dem neuesten Stand zu bleiben.

Drei Dinge, die der Makler aus dem Gedächtnis falsch wiedergegeben hätte, wurden durch eine vorab durchgeführte Überprüfung der aktuellen Unterlagen aufgefallen:

1. Der ältere VGSilentAuthClient und Numbers-SDKs wurden archiviert. Der aktuelle Pfad lautet nun einheitlich VonageClientLibrary .

2. In einigen älteren Texten wird die Methode als startCellularRequest, doch die eigentliche Methode in der ausgelieferten Bibliothek lautet startCellularGetRequest. Wir haben dies anhand des ausgecheckten Quellcodes des Pakets Verify und nicht anhand von Dokumentationen.

3. Die alte Sandbox: true Pfad ist für diese Demo nicht mehr der richtige. Der 990 „Network Registry Playground“-Ablauf verwenden wir hier.

2. Fehlerbehebung: Der Workflow läuft weiter, ohne Sie zu fragen

Bei der agentengesteuerten Entwicklung werden einige der größten Probleme erst dann offensichtlich, wenn man tatsächlich mit der App interagieren kann. In diesem Fall handelte es sich um eine offensichtliche Diskrepanz bei der Benutzererfahrung.

Claude hatte den Ablauf des Kanals als appgesteuert modelliert: Der Nutzer tippt auf die Schaltfläche „Nicht verstanden?“, die App ruft /nextauf, und der Workflow schreitet vom SMS-Code zum Voice-Fallback fort. Logisch, aber falsch.

Verify, ob die Workflows der Version 2 bei Ablauf der Kanal-Zeitüberschreitung automatisch fortgesetzt werden. Wenn der Benutzer einfach auf dem SMS-Bildschirm wartet, lässt Vonage den SMS-Kanal ablaufen und stellt den Voice-Anruf automatisch her, ohne dass /next.

Bei unserem ersten Test mit einem echten Gerät klingelte das Telefon, während in der App weiterhin „SMS“ angezeigt wurde.

Gut, dann warten wir also auf den Webhook, der meldet, dass der SMS-Kanal abgelaufen ist.
Claude hat das eingerichtet, erneut getestet, und dann habe ich sechs Minuten lang absolute Stille beobachtet: keine Webhooks zwischen dem Fallback und der abschließenden Zusammenfassung. Es stellt sich heraus, dass Callbacks für Ereignisse während des Ablaufs nur für „Silent Auth“ und WhatsApp existieren. SMS- und Voice-Ergebnisse erscheinen erst in der Zusammenfassung am Ende der Anfrage, nachdem alles abgeschlossen ist.

Da hilft auch kein Webhook.

Für diese Demo haben wir einen kleinen serverseitigen Timeout-Spiegel hinzugefügt. Die zwar praktikable, aber nicht ideale Lösung ergab sich aus der Erkenntnis, wer die Uhr kontrolliert. channel_timeout ist ein Parameter, den wir in der Anfrage festlegen, damit der Server den Zeitplan von Vonage genau kennt. Wenn ein Kanal startet, setzt der Server einen lokalen Timer auf channel_timeout + 5 Sekunden als Toleranzzeit. Wenn die Anfrage zu diesem Zeitpunkt noch auf diesem Kanal aussteht, aktualisiert der Server seinen eigenen Datensatz und protokolliert den Hop.

Die Karenzzeit stellt sicher, dass unsere Uhr erst nach der ihren anspringt, sodass die Benutzeroberfläche der Realität nie voraus ist. Die App erkennt die Änderung bei der nächsten Abfrage und wechselt den Bildschirm.

Die Kanalentwicklung wird nun von drei Faktoren bestimmt:

• Benutzer tippt

• Webhook, falls einer eintrifft

• Timeout-Spiegel

Alle drei laufen über denselben, ausschließlich vorwärtsgerichteten und durch denselben Kanal gesicherten Weiterleitungsweg. Diese Sicherung ist wichtig, da Webhooks „mindestens einmal“ und ungeordnet erfolgen: Ein verspätetes, doppeltes SMS-Ereignis darf den Status niemals aus dem Voice-Bereich zurückwirken lassen.

Außerdem gab es zwei kleinere Fehler, die mir erst beim Erstellen und Testen aufgefallen sind.

Der erste Schritt ist die Integritätsprüfung der „check_url“ Antwort. Die Antwort enthält dieselbe request_id enthalten, die zu Beginn des „Silent Auth“-Ablaufs erstellt wurde, und die App sollte diesen Wert mit der ursprünglichen Anfrage abgleichen, bevor sie fortfährt. Stimmen die Werte nicht überein, sollte die App den Ablauf abbrechen.

Diese Prüfung lässt sich leicht überspringen, da der „Happy Path“ auch ohne sie scheinbar funktioniert. Ich habe sie trotzdem hinzugefügt und das Ergebnis wie folgt protokolliert: silent_auth:integrity_check passedprotokolliert, wodurch der Sicherheitsschritt während des Tests auch in der Konsole sichtbar wurde.

Das zweite Detail ergab sich aus dem Testaufbau. Bei den Server-Tests wurde ein simulierter Verify-Client eingebunden, doch die App erstellte dennoch den echten Client, sobald Anmeldedaten in der Umgebung vorhanden waren. Das funktionierte, bis ich eine echte .env hinzufügte, um die App lokal auszuführen; daraufhin schlugen mehrere Tests fehl.

Die Lösung bestand darin, die Verknüpfungen der Applications so zu gestalten, dass sie die Testumgebung explizit berücksichtigen. Der Grundsatz „Tests greifen niemals auf die echte API zu“ muss nicht nur durch die Testkonfiguration, sondern auch durch die Abhängigkeitseinstellungen der Applications durchgesetzt werden.

4. Iterative Weiterentwicklung der Benutzererfahrung

Nachdem ich die App von Anfang bis Ende ohne Fehler zum Laufen gebracht hatte, war es an der Zeit, sie tatsächlich nützlich und benutzerfreundlich zu gestalten.

Den Entwicklermodus nutzbar machen

Die erste Version des Dev-Modus wurde als unteres Fenster geöffnet. Claude hielt das theoretisch für sinnvoll: So blieb das Formular sichtbar, und die Protokolle hatten einen vorübergehenden Speicherort.

In der Praxis verdeckte es die Schaltfläche „Anmelden“.

Das bedeutete, dass die Konsole, die Sie geöffnet hatten, um den Anmeldeablauf zu beobachten, Sie daran hindern konnte, den Anmeldeablauf zu starten. Die Lösung bestand darin, den Dev-Modus in einen Vollbildmodus zu verlagern, der erst nach dem Absenden des Formulars erscheint. Der Benutzer schließt die Aktion zunächst ab, dann übernimmt die Konsole die Anzeige, um zu zeigen, was als Nächstes geschieht.

Hätte man mit einem Mockup begonnen, das an den KI-Agenten übergeben worden wäre, hätte man dieses Problem vermeiden können.

Gruppierung nach Kanal statt Nummerierung jedes einzelnen Ereignisses

Die erste Zeitleiste hat außerdem jedem Protokollereignis ein Schritt-Abzeichen zugewiesen: SCHRITT 1/5, SCHRITT 2/5, und so weiter.

Das sah gut aus, als der Ablauf als fünf allgemeine Schritte skizziert wurde. Es ergab jedoch keinen Sinn mehr, sobald die App eine zusammengeführte Geräte-/Server-Zeitleiste anzeigte, da jede Phase mehrere Ereignisse erzeugte. Dieselbe Schrittnummer tauchte mehrmals hintereinander auf. Technisch gesehen war das zwar korrekt, aber es wirkte so, als ob die Benutzeroberfläche hängen geblieben oder verwirrt wäre.

Die wichtigere Frage für den Zuschauer war nicht: „Um welchen Schritt handelt es sich hier?“, sondern: „Welcher Kanal ist derzeit für die Authentifizierung zuständig?“

Durch die Neugestaltung wurde der Kanal somit zur zentralen visuellen Einheit. Eine Tracker-Pille zeigt oben den aktuellen Status an, Abschnittsüberschriften erleichtern das Überfliegen des scrollbaren Protokolls, und einzelne Ereignisse sind nicht mehr mit Schrittnummern versehen.

Fallback für die Demo realistisch gestalten

Der Fallback-Pfad musste angepasst werden. Die Standard-Zeitüberschreitung für den Kanal beträgt 300 Sekunden, was einer Wartezeit von fünf Minuten entspricht, bevor SMS auf Voice-Anrufe ausweichen kann. Das ist in einer Produktionsanwendung sinnvoll, für eine Demo jedoch zu langsam.

Da die Zeitüberschreitung auf dem Server festgelegt wird, verwendet die Demo-Umgebung stattdessen einen Standardwert von 60 Sekunden. Dadurch bleibt die gesamte silent_auth → SMS → Voice-Kaskade innerhalb weniger Minuten abläuft, während der gespiegelte Timer in der Konsole jeden Schritt in Echtzeit anzeigt.

Die App „vonagisieren“

Die letzte Version war visuell. Die Markenrichtlinien von Vonage beschränken die Verwendung des Logos auf genehmigte Elemente, daher ist die Demo nicht auf das Logo angewiesen, um den Eindruck einer Markenpräsenz zu vermitteln.

Stattdessen setzt die Benutzeroberfläche auf Farbpaletten und Schriftarten. „Silent Auth“ verwendet Violett, „SMS“ Magenta und „Voice“ Orange. Diese Farben dienen nicht nur der Gestaltung, sondern fungieren auch als Legende für die Zeitleiste. Dasselbe visuelle System, das die App näher an Vonage anlehnt, hilft auch dabei, zu verdeutlichen, welcher Kanal zu jedem Zeitpunkt im Ablauf aktiv ist.

After Silent Auth succeeds, the user reaches the verified state without typing an SMS or voice code.

Wo CAMARA- und Netzwerk-APIs zum Einsatz kommen

Sie können dieses Beispiel erstellen und ausführen, ohne ein Experte für Telekommunikationsstandards zu sein.

Dennoch ist es hilfreich zu wissen, wo „Silent Auth“ ins Bild passt. 

CAMARA ist ein Open-Source-Projekt unter der Schirmherrschaft der Linux Foundation, das standardisierte APIs definiert, um Entwicklern Netzwerkfunktionen zur Verfügung zu stellen. Die Nummernüberprüfung ist eine dieser APIs: Sie ermöglicht es einer Anwendung, zu überprüfen, ob eine Telefonnummer mit dem Gerät übereinstimmt, das das Mobilfunknetz nutzt, ohne dass der Nutzer einen SMS-Code eingeben muss.

Vonage stellt diese Art der netzwerkgestützten Verifizierung über „Verify v2“ und „Network Registry“ bereit. In der Praxis bedeutet dies, dass die App, die Sie hier entwickeln, nicht nur eine spezielle Vonage-Lösung ist. Sie folgt dem gleichen allgemeinen Aufbau, den Entwickler bei allen CAMARA-konformen Nummernverifizierungsabläufen vorfinden:

• The application asks for a confirmation.

• Das Netzwerk beteiligt sich am Nachweis des Besitzes der Nummer

• Der Benutzer muss kein Einmalpasswort eingeben, wenn die stille Überprüfung erfolgreich ist.

• Die App weicht auf einen Alternativweg aus, wenn der Netzwerkpfad nicht verfügbar ist.

Dieser Kontext der Standards ist zwar wichtig, aber ich glaube nicht, dass er das Tutorial dominieren sollte. Der Code-Ablauf ist der nützliche Teil: den Workflow starten, die Mobilfunkanfrage erzwingen, den zurückgegebenen Code überprüfen, den Fallback behandeln.

Was macht die „Silent Auth“ so leistungsstark?

 Die größte Stärke von „Silent Auth“ – dass der Nutzer nichts sieht – ist genau das, was es schwierig macht, das System mit Zuversicht zu entwickeln.

Eine Live-Konsole, die den Ablauf kommentiert, erwies sich als mehr als nur eine Demo-Spielerei. Auf diese Weise haben wir das oben beschriebene Verhalten beim automatischen Weiterblättern, die fehlenden Webhooks und die Timeout-Mechanismen entdeckt.

Wenn Sie Verify v2 integrieren, sollten Sie in Erwägung ziehen, einen Protokollpuffer pro Anfrage zu führen, auch wenn Sie nie eine Benutzeroberfläche dafür bereitstellen. So haben Sie eine Möglichkeit, Fragen zu beantworten, die andernfalls im stillen Ablauf untergehen würden: 

• Wurde in der Anfrage der richtige Workflow angegeben?

• Hat Vonage eine check_urlzurück?

• Hat das Gerät die Mobilfunkanfrage versucht?

• Hat die request_id Integritätsprüfung erfolgreich?

• Welcher Ausweichkanal ist derzeit aktiv?

• Stimmte die abschließende Zusammenfassung mit den Angaben in der Benutzeroberfläche überein?

Einige Ideen zur Erweiterung des Beispiels:

• Einen WhatsApp-Kanals. Verify v2 unterstützt WhatsApp im Workflow; fügen Sie ihn zwischen SMS und Voice ein.

• Persistieren verifizierte Sitzungen für angemeldete Benutzer. In der Demo werden alle Daten absichtlich gelöscht; fügen Sie Sitzungen hinzu, die auf dem Schlüsselbund basieren.

• Hinzufügen SIM-Swap-Prüfungen Prüfungen. Sie könnten „Silent Auth“ mit der Vonage SIM-Swap-API kombinieren, um ein zusätzliches Signal zur Besitzüberprüfung und Risikobewertung zu erhalten.

• Verbessern die Zahlenkompetenz für mehr Sicherheit. Nutzen Sie Vonage Number Insight , bevor Sie mit der Verifizierung beginnen, um das Nummernformat, den Netzbetreiber und die Erreichbarkeitssignale zu verstehen.

• Hinzufügen Android Unterstützung. Das gleiche Backend bedient jeden Client, der eine über das Mobilfunknetz zwangsgeleitete Anfrage stellen kann.

• Die Zeitachse weiter vorantreiben – : Exportieren Sie das zusammengeführte Protokoll als JSON für Fehlerberichte oder geben Sie eine gespeicherte Zeitleiste in der Konsole wieder.[HS4] 

Häufig gestellte Fragen zur reibungslosen, geräuschlosen Authentifizierung

Was ist „Silent Network Authentication“ und wie wird damit eine Telefonnummer unter iOS Verified?

Bei der „Silent Network Authentication“ wird eine Telefonnummer Verified, indem der Mobilfunkanbieter gebeten wird, zu bestätigen, dass die SIM-Karte im Gerät mit der zu überprüfenden Nummer übereinstimmt. Unter iOS erhält Ihre App eine check_url von Vonage Verify v2 und folgt dieser URL über Mobilfunkdaten unter Verwendung der Vonage-iOS-Client-Bibliothek. Bestätigt der Netzbetreiber die Übereinstimmung, erhält die App einen Code und sendet diesen an Ihr Backend, um die Verifizierung abzuschließen.

Was ist stille Authentifizierung?

„Silent Authentication“ ist die Bezeichnung von Vonage für diesen SIM-gebundenen Verifizierungsablauf. Es handelt sich um eine Art der Telefonnummernverifizierung, bei der der Nutzer keinen Einmalcode eingeben muss. Der Netzbetreiber bestätigt die Zuordnung der Telefonnummer zum Gerät im Hintergrund.

Wie funktioniert die stille Authentifizierung?

Ihr Backend erstellt eine „Verify v2“-Anfrage mit „silent_auth“ als erstem Workflow-Kanal. Ist die Nummer berechtigt, gibt Vonage eine check_urlzurück. Die iOS-App öffnet diese URL über Mobilfunkdaten, empfängt einen Code und sendet diesen an Ihr Backend zurück. Ihr Backend überprüft den Code anschließend mit Verify v2.

Funktioniert die „Silent Authentication“ über WLAN unter iOS?

Für die standardmäßige stille Authentifizierung ist die check_url -Anfrage muss über Mobilfunkdaten erfolgen. Das Smartphone kann mit einem WLAN-Netzwerk verbunden sein, aber die „check_url“ -Anfrage selbst muss über die Mobilfunkverbindung erfolgen. Die Beispiel-App verwendet VGCellularRequestClient aus der Vonage-iOS-Client-Bibliothek, um sicherzustellen, dass diese Anfrage über Mobilfunk erfolgt.

Inwiefern unterscheidet sich die „Silent Authentication“ von Passkeys und FIDO2?

Passkeys und FIDO2 sind gerätegebundene Authentifizierungsmethoden. „Silent Authentication“ ist eine SIM-gebundene Überprüfung der Telefonnummer. Sie lösen unterschiedliche Probleme und können gemeinsam genutzt werden. Beispielsweise könnte eine App Passkeys für die Anmeldung verwenden und „Silent Authentication“ als unkomplizierte Überprüfung des Telefonbesitzes bei der Registrierung oder der Wiederherstellung des Accounts nutzen.

Was passiert, wenn „Silent Auth“ für eine Telefonnummer nicht unterstützt wird?

Ihre App sollte auf einen Fallback zurückgreifen. In diesem Beispiel beginnt der Workflow mit „silent_auth“, wechselt dann auf SMS und anschließend auf Voice-Anruf. Falls die stille Authentifizierung aufgrund der Netzabdeckung des Anbieters, der Netzwerkbedingungen oder des Gerätestatus nicht abgeschlossen werden kann, kann sich der Nutzer dennoch mit einem Code Verify.

Wie teste ich „Silent Auth“ ohne echtes Handy im Mobilfunknetz?

Verwenden Sie den „Network Registry Playground“ / „Virtual Operator“ mit 990 Numbers. Zum Beispiel: 99012345670 zeigt einen erfolgreichen Verbindungsweg, während 99012345671 einen Ausweichpfad demonstrieren kann. Dies ist nützlich für die lokale Entwicklung und CI, ersetzt jedoch nicht das Testen der echten Mobilfunk- check_url Ablauf auf einem physischen iPhone.

Wie sich APIs zur Telefonverifizierung entwickeln

Der vollständige Quellcode befindet sich auf GitHub. Erstellen Sie einen Fork, führen Sie die Demo aus und nutzen Sie das Repo als Arbeitsgrundlage, bevor Sie damit beginnen, den Ablauf an Ihre eigene App anzupassen.

Ein paar spannende Entwicklungen, die du im Auge behalten solltest

Die Verfügbarkeit wird ausgeweitet.
Vonage hat gerade die Funktionen „Silent Authentication“ und „SIM-Swap-Erkennung“ in Kanada auf den Markt gebracht und ergänzt damit das bestehende Angebot in den USA, Großbritannien und Westeuropa. Die Verbreitung dieser Funktionen nimmt richtig Fahrt auf!

Silent Auth Advanced entwickelt sich rasant weiter.
Dieses Tutorial behandelt den Standardablauf von „check_url“, für den Mobilfunkdaten erforderlich sind. „Advanced“ (derzeit in der Alpha-Phase) ist die Weiterentwicklung von TS.43, die Silent Auth auf WLAN und VPN ausweitet und damit die Anforderung „force-cellular“ beseitigt, die in diesem Beispiel umgangen wird.

 Das Ökosystem orientiert sich zunehmend an diesem Modell.
Große Netzbetreiberkonsortien in Nordamerika und Europa stellen nun netzwerkgestützte Identitätssignale über CAMARA-konforme APIs bereit, — was bedeutet, dass das, was Sie heute auf Vonage aufbauen, bereits den Standards entspricht, auf die sich die Branche einigt. Lydia, eine der am schnellsten wachsenden Neobanken Europas, hat „Vonage Verify“ mit „Silent Authentication“ implementiert und konnte so die Latenz bei der Authentifizierung um 50 % reduzieren sowie die Konversionsrate bei der Registrierung um 26 % steigern, ohne dass für den Nutzer ein zusätzlicher Schritt erforderlich war.