Stille Authentifizierung Asynchrone Implementierung

Einführung

Eine asynchrone Implementierung ähnelt sehr der synchron Methode; anstatt den Geräte-Client zu verwenden, um eine Reihe von Aufrufen zu tätigen, wird jeder Teil des Arbeitsablaufs in Webhook-Rückrufe an eine von Ihnen definierte URL gesendet.

Dieser Leitfaden erklärt, wie die stille Authentifizierung mit dem asynchronen Ansatz implementiert wird, bei dem Ihr Backend einen Callback einrichtet, um das Authentifizierungsergebnis zu erhalten.

Erstellen einer Applikation

Um zu beginnen, besuchen Sie die Seite Entwickler-Dashboard um Ihre Anwendung zu erstellen:

• Vergewissern Sie sich, dass Verify unter "Fähigkeiten" aktiviert ist.
• Konfigurieren Sie die Status-URL für den Empfang von Callback-Ereignissen.
• Erzeugen einer JWT unter Verwendung der Anwendungs-ID und des privaten Schlüssels der Anwendung.

Trigger-Verifizierung

Um den Prozess der stillen Authentifizierung zu starten, stellen Sie eine Anfrage an /verify. Im folgenden Beispiel wird die Arbeitsablauf legt fest, dass Verify zunächst versucht, die stille Authentifizierung zu verwenden. Wenn die Anfrage aus irgendeinem Grund fehlschlägt, wird auf SMS zurückgegriffen, gefolgt von einem OTP per Sprachanruf.

Um das Beispiel auszuführen, ersetzen Sie die folgenden Variablen im Beispielcode durch Ihre eigenen Werte:

Antwort

Wenn die Anfrage erfolgreich ist, gibt die Antwort HTTP 200 mit dem check_url im Körper, die wir im nächsten Schritt benötigen:

Liegt ein Fehler in der Anfrage vor, z. B. eine falsch formatierte Telefonnummer, enthält die Antwort eine HTTP 422 Fehler wie dieser:

Da wir die asynchrone Implementierung verwenden, erhalten Sie parallel zur API-Antwort eine Rückruf (oder Webhook) an die in den Einstellungen Ihrer Dashboard-Anwendung angegebene URL, um Sie über den Fortschritt der Anfrage zu informieren.

Während des API-Aufrufs an /verifyführt die Verify-API interne Vorprüfungen durch. Wenn alles in Ordnung ist, enthält der Callback den folgenden Body:

Bis der Antrag abläuft oder storniert wird, check_url wird verwendet, um eine Überprüfung der stillen Authentifizierung durchzuführen, indem Senden der Auth-URL. Wenn Sie diesen Rückruf erhalten, müssen Sie eine

-Anfrage an die check_url von dem mobilen Gerät, das Sie zu authentifizieren versuchen.

Wenn eine dieser Vorprüfungen fehlschlägt, z. B. aufgrund eines Netzwerkfehlers oder eines nicht unterstützten Operators, sieht der Callback wie folgt aus:

Wenn Ihr /verify Anfrage einen Rückfallkanal enthält, verwendet Verify diesen Kanal weiter, wie im folgenden Sequenzdiagramm dargestellt:

Auth URL senden

Sobald Sie die

-Anfrage gestellt haben, erhalten Sie eine oder mehrere HTTP 302 Umleitungen je nach Gebiet und Träger des Zielgeräts:

Die Befolgung der Weiterleitungen führt entweder zu einer HTTP 200 oder HTTP 4xx Antwort je nach Ergebnis. Wenn es ein Problem mit dem Netzwerk gibt, könnten Sie eine Antwort wie diese sehen:

Eine vollständige Liste der möglichen Fehlercodes finden Sie in der API-Spezifikation.

Wenn die Anfrage gültig ist, erhalten Sie eine HTTP 200 Antwort mit Ihrer request_id und eine code:

Überprüfen Sie den Verifizierungscode

Sobald der Endbenutzer den Code erhält, muss Ihre Client-Anwendung eine

-Anfrage an die /v2/verify/{request_id} Endpunkt und ersetzt damit {request_id} mit der ID, die Sie beim letzten Anruf erhalten haben.

Um das Beispiel auszuführen, ersetzen Sie die folgenden Variablen im Beispielcode durch Ihre eigenen Werte:

Wenn der Code gültig ist, erhalten Sie einen Rückruf mit dem Status completed:

Wenn ein Fehler auftritt, wird "Ungültiger Code" angezeigt:

Sie erhalten dann einen letzten Rückruf mit dem Ergebnis der Prüfung. Im Erfolgsfall erhalten Sie einen Callback mit "status": "completed":

Ist dies nicht der Fall, z. B. wenn der Benutzer abgewiesen wurde, wird dies in der status Feld:

An diesem Punkt ist die Überprüfung der stillen Authentifizierung abgeschlossen.