Einführung der stillen Authentifizierung von Vonage

Bitte beachten: Die stille Authentifizierung ist jetzt in der Beta-Phase. Mehr darüber erfahren Sie in unserer Ankündigung.

Vonage freut sich über die neue Stille Authentifizierung in unsere Verify API aufzunehmen! Der Kanal "Silent Authentication" wurde als Teil von Verify V2 hinzugefügt und befindet sich derzeit in der Alpha-Produktphase. In diesem Artikel gehen wir darauf ein, was er ist, was er kann und wie man ihn benutzt. Um zu beginnen, beantworten wir die folgenden Fragen:

Was ist stille Authentifizierung?

Die stille Authentifizierung ist eine neuere Entwicklung im Bereich der persönlichen Authentifizierungsabläufe, die das Teilnehmer-Identitätsmodul (SIM) Ihres Mobiltelefons als Ihre Identität verwendet, die mit den Aufzeichnungen des Netzbetreibers abgeglichen wird, um sicherzustellen, dass Ihre Nummer aktiv und echt ist. Sobald eine Anfrage verifiziert wurde, kann ein Anbieter/Kunde jedes Mal, wenn ein Benutzer sich authentifizieren will, denselben Endpunkt ansteuern, der so lange gültig ist, bis die Anfrage abläuft oder vom Kunden abgebrochen wird. Dies bedeutet im Endeffekt Folgendes: Verwendung von Ihr Mobiltelefon als Ihr Passwort.

Was sind die Vorteile der Stillen Authentifizierung?

One-Time-Passwörter (OTP) werden weltweit in großem Umfang für die Zwei-Faktor-Authentifizierung verwendet. Die de-facto Hauptanwendung unserer Verify API ist die Verwendung eines OTPs, das an die SMS eines Kunden gesendet wird. Aber seien wir mal ehrlich: Als Kunde sind OTPs lästig. Sicher, es ist eine zusätzliche Sicherheitsebene (wir werden gleich darauf eingehen, warum das nicht unbedingt stimmt). Doch für einen Anbieter, der auf möglichst wenige Klicks oder Navigationspunkte in einem Arbeitsablauf angewiesen ist (wie z. B. im E-Commerce), erhöhen Sie den Widerstand, einen Vorgang abzuschließen (d. h. einen Artikel zu kaufen). Im E-Commerce wird in der Regel der Weg des geringsten Widerstands gewählt. Aus dieser Perspektive entfällt mit Silent Authentication dieser zusätzliche Schritt bei der Anmeldung oder beim Auschecken des Warenkorbs vollständig.

Auch die Sicherheit ist ein Thema - es ist ein weit verbreiteter Irrglaube, dass 2FA den Benutzerfluss extrem schwer zu knacken macht, aber dabei wird nicht berücksichtigt, dass SMS-Phishing ein weit verbreiteter Angriffsvektor ist, der von Betrügern genutzt wird. Durch die Verlagerung der Authentifizierung direkt zwischen dem Anbieter und dem mobilen Gerät wird die Gefahr des Phishings beseitigt.

Gibt es Nachteile?

Wie es sich für Entwickler gehört, würden wir unsere Arbeit nicht richtig machen, wenn wir nicht darauf hinweisen würden, dass es bei der Benutzerüberprüfung kein Patentrezept gibt - genau wie in der Technik gibt es Kompromisse. Es gibt zwei Hauptnachteile bei der Verwendung:

• Die stille Authentifizierung hat mit der SMS-Verifizierung gemeinsam, dass der Benutzer ein mobiles Gerät benötigt - daran führt kein Weg vorbei. Statistiken zeigen zwar, dass der Smartphone-Besitz in den westlichen Ländern bald bei über 90 % liegen wird (88 % der britischen Bevölkerung besitzen beispielsweise ein Smartphone), aber dabei wird nicht berücksichtigt, dass es weltweit Menschen gibt, bei denen die Qualität der Dienste oder die wirtschaftlichen Verhältnisse ein aktives Hindernis darstellen könnten.

• Das Mobiltelefon der Benutzer müssen die Mobilfunkdaten aktiviert sein. Das ist ein kleiner Schritt, aber dennoch eine zusätzliche Komplikation in einem Prozess, der so einfach wie möglich sein soll.

So stellen Sie eine Anfrage zum Verify der stillen Authentifizierung

Synchrone vs. Asynchrone Integrationen

Ich werde Ihnen die synchrone Methode zur Implementierung der stillen Authentifizierung zeigen, aber es ist nichts wert, was auch nicht geht: Diese synchrone Methode verlässt sich darauf, dass der Geräte-Client eine Reihe von Aufrufen tätigt, um sie abzuschließen, aber Sie können einen asynchronen Workflow verwenden, ohne etwas ändern zu müssen. Jeder Teil des Workflows ist auch in Webhook-Callbacks an die URL der Wahl im Anwendungs-Setup enthalten.

Fangen wir also mit der synchronen Implementierung an. Als Erstes wollen wir einen Aufruf machen, um den Prozess zu starten:

Vorausgesetzt, Sie haben keine Drosselgrenzen erreicht und das Autorisierungs-Token ist korrekt, sollten Sie eine HTTP 202 Antwort mit Ihrer request_id als Referenz und einem check_url:

{
  "request_id": "c11236f4-00bf-4b89-84ba-88b25df97315",
  "check_url": "https://api.nexmo.com/v2/verify/31eaf23d-b2db-4c42-9d1d-e847e75ab330/silent-auth/redirect"
}

Die check_url ist ein Link, dem Sie folgen müssen, um den Prozess fortzusetzen. Sie möchten also, dass Ihr clientseitiger Code genau das tut. Wenn Sie ihm folgen, erhalten Sie eine variable Anzahl von 302 Weiterleitungen, je nach Gebiet und Anbieter, den das Zielgerät verwendet:

HTTP/1.1 302 Found
Location: https://eu.api.silentauth.com/phone_check/v0.2/checks/31eaf23d-b2db-4c42-9d1d-e847e75ab330/redirect

Wenn Sie den Weiterleitungen folgen, erhalten Sie entweder eine HTTP 200 oder HTTP 409 je nachdem, ob die Anfrage gültig ist. Wenn es ein Problem bei der Nutzung des Netzes gibt, erhalten Sie die folgende Antwort:

HTTP/1.1 409 CONFLICT
Content-Type: application/json

{
  "title": "Network error",
  "detail": "The Silent Auth request could not be completed due to formatting or the carrier is not supported."
}

Aber wenn alles gut geht, erhalten Sie eine HTTP 200 mit der folgenden Beispiel-Nutzlast:

{
  "request_id": "31eaf23d-b2db-4c42-9d1d-e847e75ab330",
  "code": "si9sfG"
}

Der letzte Teil des Arbeitsablaufs besteht darin, die code zu überprüfen, wie bei den anderen Verify-Kanälen auch.

POST https://api.nexmo.com/v2/verify/31eaf23d-b2db-4c42-9d1d-e847e75ab330 HTTP/1.1

Content-Type: application/json
{
  "code": "si9sfG"
}

Die Antworten sind dieselben wie bei der Überprüfung eines Codes, der von anderen Arbeitsabläufen wie z. B. SMS geliefert wurde:

{
   "request_id": "31eaf23d-b2db-4c42-9d1d-e847e75ab330",
   "status": "completed"
}

Oder, wenn ein Fehler vorliegt:

{
   "title": "Invalid Code",
   "type": "https://www.developer.vonage.com/api-errors/verify#invalid-code",
   "detail": "The code you provided does not match the expected value.",
   "instance": "bf0ca0bf927b3b52e3cb03217e1a1ddf"
}

Ja, es gibt eine ganze Reihe von Schritten für den Entwickler diese Lösung zu implementieren, aber die Schönheit liegt in der Endnutzer eine nahtlose Erfahrung zu sehen. Korrektes Telefon, gültiger Anbieter? Fertig, Sie sind eingeloggt!

Dranbleiben

Silent Authentication ist der Beginn einer Reihe von Produkten, an denen wir in diesem Jahr arbeiten. Sie können sich bei uns registrieren registrieren, wenn Sie die Silent Authentication nutzen möchten, um die Developer Preview zu aktivieren. Und in der Zwischenzeit haben wir einige tolle Produkte, auf die wir uns im Jahr 2023 freuen. Möchten Sie auf dem Laufenden bleiben? Folgen Sie unserem Twitter Developer Account oder sehen Sie sich unsere Entwickler-Dokumente an.