https://d226lax1qjow5r.cloudfront.net/blog/blogposts/vonage-verify-v2-is-now-ga-for-2fa-integrations/verify-v2_ga.png

Vonage Verify V2 ya es GA para integraciones 2FA

Publicado el May 22, 2023

Tiempo de lectura: 3 minutos

Nos complace anunciar que Verify, nuestra API para la autenticación de dos factores (2FA), acaba de lanzar la versión 2 para disponibilidad general. Esta evolución de nuestra solución 2FA ha sido diseñada para funcionar mejor para los desarrolladores mediante el uso de Webhooks para integraciones asíncronas y ofreciendo más opciones y flexibilidad. Veamos las diferencias entre la V1 y la V2. También puede consultar una guía completa para cambiar de versión en esta página de nuestra documentación.

Adiós al sondeo, hola a los webhooks

La versión 1 de Verify fue diseñada para tener un flujo más sincrónico - un ejemplo de esto es después de iniciar una solicitud, la API necesita ser interrogada si usted necesita saber el estado de la solicitud antes de que el usuario envíe un código PIN (que efectivamente cuenta como el "inicio" y "final" del ciclo de vida de la solicitud).

La primera iteración de Verify se construyó en torno a un flujo síncrono, con un sondeo de la API necesario para comprobar el estado de una solicitud tras su inicio y antes de enviar el código PIN del usuario.

En cambio, Verify versión 2 aprovecha la potencia de los webhooks. Iniciar una solicitud ahora le proporciona un GUID único. Suponiendo que los JWT sean su método de autorización, su integración escuchará los webhooks entrantes correspondientes a la solicitud de GUID para actualizaciones. Los puntos finales asociados con estos webhooks son:

  • Iniciar la solicitud

  • Verificar el PIN del usuario

  • Cancelar una solicitud

Protección reforzada contra el fraude

Con el aumento de la actividad fraudulenta que explota las API de comunicaciones, hemos integrado el sistema antifraude Verify con la versión 2. Este sistema detecta actividades sospechosas y activa un bloqueo de red. Para mayor flexibilidad, los usuarios también pueden personalizar esta función en función de sus necesidades.

Métodos de entrega mejorados

El cambio más significativo que hemos introducido en la API es la adición de nuevas opciones de canales de comunicación. Al iniciar una nueva solicitud, se pueden utilizar los siguientes métodos existentes:

  • SMS

  • Voz Texto a voz (TTS)

Ya puedes utilizar estos nuevos métodos:

  • WhatsApp

  • Correo electrónico

  • Autenticación silenciosa

Hago que la expansión del producto sea de... ¡200%!

Control mejorado del flujo de trabajo

En relación con los nuevos canales, ahora puede controlar exactamente cómo se estructura el flujo de trabajo de sus solicitudes. Antes, se enviaba un workflow_id en la solicitud, tomado de una lista predefinida en nuestro portal para desarrolladores. En cambio, para V2, puede incluir una carga útil personalizada para su flujo de trabajo. Por ejemplo, si desea que el orden de intento de los canales sea Autenticación silenciosa -> Correo electrónico -> SMS, la solicitud tendría el siguiente aspecto:

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

Generación de PIN personalizados

Los desarrolladores también pueden enviar un código personalizado para los canales que lo requieran (es decir, todos excepto WhatsApp Interactivo y Autenticación Silenciosa). Este código puede tener entre 4 y 10 caracteres de longitud y es alfanumérico. Este es un ejemplo de la carga JSON que se envía cuando se utiliza un PIN generado por uno mismo:

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

Más REST, por favor

La versión 2 de Verify hace un mejor uso de los códigos de respuesta HTTP. Sí, sí, de acuerdo: no es REST (sólo quería ponerlo en el título), sino un mejor uso del protocolo HTTP. He aquí algunos ejemplos:

  • Al iniciar una petición que ya se ha ejecutado, se obtiene un mensaje 409 respuesta.

  • Alcanzar el límite de tarifa ahora te da un 429

  • Una carga útil no válida para los puntos finales de inicio de solicitud o de envío de PIN le da un 422

  • Este es un caso de uso bastante agradable: si envías un PIN incorrecto demasiadas veces, eventualmente obtienes un 410 para indicar que la entidad de solicitud ya no está disponible para ningún cambio de estado.

¿Qué vas a construir?

Los nuevos canales que hemos lanzado ahora ofrecen a los desarrolladores una gran variedad de opciones para integrar 2FA en sus sistemas, proyectos paralelos y aplicaciones empresariales. La pregunta es: ¿qué ha creado usted? Un apasionado proyecto paralelo convertido en startup con Laravel o Rails? ¿Un despliegue en una empresa con arquitectura de microservicios Node? ¡Queremos saberlo! Dirígete a nuestro Community Slack para hablar con nosotros.

Compartir:

https://a.storyblok.com/f/270183/400x385/12b3020c69/james-seconde.png
James SecondePromotor senior de desarrollo PHP

Actor de formación con una disertación sobre la comedia, llegué al desarrollo de PHP a través de la escena de las reuniones. Puedes encontrarme hablando y escribiendo sobre tecnología, o tocando/comprando discos raros de mi colección de vinilos.