Vonage Verify V2 ist jetzt GA für 2FA-Integrationen

Wir freuen uns, Ihnen mitteilen zu können, dass Verify, unsere API für die Zwei-Faktor-Authentifizierung (2FA), ab sofort in der Version 2 allgemein verfügbar ist! Diese Weiterentwicklung unserer 2FA-Lösung wurde so konzipiert, dass sie für Entwickler besser funktioniert, indem sie Webhooks für asynchrone Integrationen verwendet und mehr Optionen und Flexibilität bietet. Schauen wir uns die Unterschiede zwischen V1 und V2 an. Sie können auch eine umfassende Anleitung zum Versionswechsel auf dieser Seite in unserer Dokumentation.

Auf Wiedersehen Polling, Hallo Webhooks

Version 1 von Verify wurde für einen eher synchronen Ablauf konzipiert - ein Beispiel hierfür ist, dass die API nach dem Starten einer Anfrage abgefragt werden muss, wenn Sie den Status der Anfrage wissen müssen, bevor der Benutzer einen PIN-Code eingibt (was effektiv als "Start" und "Ende" des Anfrage-Lebenszyklus gilt).

Die erste Iteration von Verify basierte auf einem synchronen Ablauf, wobei die API-Abfrage erforderlich war, um den Status einer Anfrage nach ihrer Initiierung und vor der Übermittlung des PIN-Codes des Benutzers zu überprüfen.

Im Gegensatz dazu nutzt Verify Version 2 die Möglichkeiten von Webhooks. Beim Initiieren einer Anfrage erhalten Sie jetzt eine eindeutige GUID. Unter der Annahme, dass JWTs Ihre Autorisierungsmethode sind, wird Ihre Integration auf eingehende Webhooks warten, die der GUID-Anforderung für Updates entsprechen. Die zugehörigen Endpunkte mit diesen Webhooks sind:

• Initiieren Sie den Antrag

• Überprüfen Sie die PIN des Benutzers

• Eine Anfrage stornieren

Verstärkter Schutz vor Betrug

Angesichts der zunehmenden betrügerischen Aktivitäten, bei denen Kommunikations-APIs ausgenutzt werden, haben wir das Verify Anti-Betrugs-System in Version 2 integriert. Dieses System erkennt verdächtige Aktivitäten und löst eine Netzwerksperre aus. Für zusätzliche Flexibilität können Benutzer auch diese Funktion anpassen diese Funktion bei Bedarf an ihre Anforderungen anpassen.

Verbesserte Liefermethoden

Die wichtigste Änderung, die wir an der API vorgenommen haben, ist das Hinzufügen neuer Kommunikationskanaloptionen. Wenn Sie eine neue Anfrage starten, können die folgenden bestehenden Methoden verwendet werden:

• SMS

• Sprache Text to Speech (TTS)

Sie können nun diese neuen Methoden verwenden:

• WhatsApp

• E-Mail

• Stille Authentifizierung

Ich mache daraus eine Produktexpansion von... 200%!

Verbesserte Workflow-Kontrolle

Im Zusammenhang mit den neuen Kanälen können Sie nun genau steuern, wie Ihr Anfrage-Workflow strukturiert ist. Bisher haben Sie eine workflow_id in der Anfrage, die aus einer vordefinierten Liste in unserem Entwicklerportal. Stattdessen können Sie für V2 eine benutzerdefinierte Nutzlast für Ihren Workflow angeben. Wenn Sie z. B. möchten, dass die versuchte Reihenfolge der Kanäle Silent Auth -> E-Mail -> SMS lautet, würde die Anfrage wie folgt aussehen:

{
   "brand": "ACME, Inc",
   "workflow": [
      {
         "channel": "silent_auth",
         "to": "44770090000X"
      },
	  {
         "channel": "email",
         "to": "alice@company.com",
         "from": "bob@company.com"
      },
      {
         "channel": "sms",
         "to": "44770090000X"
      }
   ]
}

Benutzerdefinierte PIN-Generierung

Die Entwickler können auch einen benutzerdefinierten Code für Kanäle senden, die dies erfordern (d. h. alle außer WhatsApp Interactive und Silent Authentication). Dieser Code kann zwischen 4 und 10 Zeichen lang sein und ist alphanumerisch. Hier ist ein Beispiel für die JSON-Nutzdaten, die bei Verwendung Ihrer eigenen generierten PIN gesendet werden:

{
   "brand": "ACME, Inc",
   "code" : "R4Fe4dR1Qz",
   "workflow": [
      {
         "channel": "sms",
         "to": "447700900000"
      }
   ]
}

Mehr REST, bitte

Version 2 von Verify macht besseren Gebrauch von HTTP-Antwortcodes. Ja, ja, OK: also nicht REST (ich wollte es nur in die Überschrift packen), sondern eine bessere Nutzung des HTTP-Protokolls. Hier sind einige Beispiele:

• Wenn Sie eine bereits gelaufene Anfrage starten, erhalten Sie eine 409 Antwort.

• Bei Überschreitung der Ratengrenze erhalten Sie jetzt eine Standard 429

• Eine ungültige Nutzlast für die Endpunkte "Request Start" oder "PIN Submission" gibt Ihnen eine 422

• Dies ist ein sehr schöner Anwendungsfall: Wenn Sie zu oft eine falsche PIN eingeben, erhalten Sie schließlich eine 410 um anzuzeigen, dass die Anfragestelle nicht mehr für Statusänderungen verfügbar ist.

Was werden Sie bauen?

Die neuen Kanäle, die wir jetzt eingeführt haben, bieten Entwicklern eine Fülle von Möglichkeiten zur Integration von 2FA in ihre Systeme, Nebenprojekte und Unternehmensanwendungen. Die Frage ist, was haben Sie gebaut? Ein leidenschaftliches Nebenprojekt, das zu einem Startup mit Laravel oder Rails? Ein Rollout in einem Unternehmen mit Node-Microservice-Architektur? Wir wollen es wissen! Gehen Sie zu unserem Community Slack um mit uns zu sprechen.