Vonage Verify V2 est maintenant disponible pour les intégrations 2FA

Nous sommes ravis d'annoncer que Verify, notre API pour l'authentification à deux facteurs (2FA), vient de voir sa version 2 publiée pour une disponibilité générale ! Cette évolution de notre solution 2FA a été conçue pour mieux fonctionner pour les développeurs en utilisant des Webhooks pour les intégrations asynchrones et en offrant plus d'options et de flexibilité. Passons en revue les différences entre la V1 et la V2. Vous pouvez également consulter un guide complet sur le passage d'une version à l'autre sur cette page dans notre documentation. changement de version sur cette page de notre documentation.

Au revoir les sondages, bonjour les webhooks

La version 1 de Verify a été conçue pour avoir un flux plus synchrone - par exemple, après avoir lancé une demande, l'API doit être interrogée si vous avez besoin de connaître l'état de la demande avant que l'utilisateur ne soumette un code PIN (ce qui compte effectivement comme le "début" et la "fin" du cycle de vie de la demande).

La première itération de Verify s'articulait autour d'un flux synchrone, avec une interrogation de l'API nécessaire pour vérifier l'état d'une demande après son lancement et avant de soumettre le code PIN de l'utilisateur.

En revanche, la version 2 de Verify exploite la puissance des webhooks. Le lancement d'une demande vous fournit désormais un GUID unique. Si les JWT sont votre méthode d'autorisation, votre intégration écoutera les webhooks entrants correspondant à la demande de mise à jour du GUID. Les points de terminaison associés à ces webhooks sont les suivants :

• Initier la demande

• Verify the user's PIN (vérifier le code PIN de l'utilisateur)

• Annuler une demande

Renforcement de la protection contre la fraude

Face à la recrudescence des activités frauduleuses exploitant les API de communication, nous avons intégré le système anti-fraude Verify. système anti-fraude Verify à la version 2. Ce système détecte les activités suspectes et déclenche un blocage du réseau. Pour plus de flexibilité, les utilisateurs peuvent également personnaliser cette fonction cette fonction en fonction de leurs besoins.

Méthodes de livraison améliorées

La modification la plus importante que nous avons apportée à l'API est l'ajout de nouvelles options de canaux de communication. Lorsque vous lancez une nouvelle demande, les méthodes existantes suivantes peuvent être utilisées :

• SMS

• Voice Text to Speech (TTS)

Vous pouvez maintenant utiliser ces nouvelles méthodes :

• WhatsApp

• Courriel

• Authentification silencieuse

Je parle d'une expansion du produit de... 200% !

Contrôle amélioré du flux de travail

En ce qui concerne les nouveaux canaux, vous pouvez désormais contrôler exactement la façon dont le flux de travail de votre demande est structuré. Auparavant, vous envoyiez un workflow_id dans la demande, à partir d'une liste prédéfinie de liste prédéfinie dans notre portail pour développeurs. Au lieu de cela, pour la V2, vous pouvez inclure une charge utile personnalisée pour votre flux de travail. Par exemple, si vous souhaitez que l'ordre de tentative des canaux soit Silent Auth -> Email -> SMS, la demande ressemblerait à ceci :

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

Génération de codes PIN personnalisés

Les développeurs peuvent également envoyer un code personnalisé pour les canaux qui le nécessitent (c'est-à-dire tous les canaux à l'exception de WhatsApp Interactive et de l'authentification silencieuse). Ce code peut comporter entre 4 et 10 caractères alphanumériques. Voici un exemple de la charge utile JSON envoyée lorsque vous utilisez votre propre code PIN :

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

Plus de REST, s'il vous plaît

La version 2 de Verify utilise mieux les codes de réponse HTTP. Oui, oui, OK : il ne s'agit donc pas de REST (je voulais juste le mentionner dans le titre), mais d'une meilleure utilisation du protocole HTTP. Voici quelques exemples :

• Lorsque vous lancez une requête qui a déjà été exécutée, vous obtenez un message de type 409 qui s'affiche à l'écran.

• Le dépassement de la limite tarifaire donne désormais droit à un montant standard de 429

• Une charge utile non valide, que ce soit pour le point de départ de la demande ou pour le point d'arrivée de la soumission du code PIN, donne lieu à un message de type 422

• Il s'agit d'un cas d'utilisation assez intéressant : si vous soumettez un code PIN incorrect trop souvent, vous finirez par obtenir un message de type 410 pour indiquer que l'entité de demande n'est plus disponible pour aucun changement d'état.

Qu'allez-vous construire ?

Les nouveaux canaux que nous avons lancés offrent aux développeurs une multitude d'options pour intégrer 2FA dans leurs systèmes, leurs projets secondaires et leurs applications d'entreprise. La question est de savoir ce que vous avez construit. Un projet secondaire passionné devenu une startup avec Laravel ou Rails ? Un déploiement au sein d'une entreprise avec une architecture de microservices Node ? Nous voulons savoir ! Rendez-vous sur notre communauté Slack pour nous en parler.