O Vonage Verify V2 já está disponível para integrações de autenticação de duas etapas (2FA)

Estamos muito animados em anunciar que o Verify, nossa API para Autenticação de Dois Fatores (2FA), acaba de lançar a Versão 2 para disponibilidade geral! Essa evolução da nossa solução de 2FA foi projetada para atender melhor aos desenvolvedores, utilizando Webhooks para integrações assíncronas e oferecendo mais opções e flexibilidade. Vamos examinar as diferenças entre a V1 e a V2. Você também pode conferir um guia completo sobre mudar de versão nesta página da nossa documentação.

Adeus, polling; olá, webhooks

A versão 1 do Verify foi projetada para ter um fluxo mais síncrono — um exemplo disso é que, após iniciar uma solicitação, é necessário consultar a API se você precisar saber o status da solicitação antes que o usuário envie um código PIN (o que, na prática, corresponde ao “início” e ao “fim” do ciclo de vida da solicitação).

A primeira versão do Verify foi desenvolvida com base em um fluxo síncrono, exigindo a consulta à API para verificar o status de uma solicitação após seu início e antes do envio do código PIN do usuário.

Em contrapartida, o Verify Versão 2 aproveita o poder dos webhooks. Ao iniciar uma solicitação, você recebe agora um GUID exclusivo. Supondo que os JWTs sejam seu método de autorização, sua integração ficará atenta aos webhooks recebidos correspondentes ao GUID da solicitação para obter atualizações. Os endpoints associados a esses webhooks são:

• Iniciar a solicitação

• Verifique o PIN do usuário

• Cancelar uma solicitação

Proteção reforçada contra fraudes

Com o aumento das atividades fraudulentas que exploram as APIs de comunicação, integramos o Sistema Verify Anti-Fraude à Versão 2. Esse sistema detecta atividades suspeitas e aciona um bloqueio de rede. Para maior flexibilidade, os usuários também podem personalizar esse recurso de acordo com suas necessidades, se necessário.

Métodos de entrega aprimorados

A mudança mais significativa que fizemos na API foi a adição de novas opções de canais de comunicação. Ao iniciar uma nova solicitação, é possível utilizar os seguintes métodos já existentes:

• SMS

• Conversão de texto em voz (TTS)

Agora você pode usar esses novos métodos:

• WhatsApp

• E-mail

• Autenticação silenciosa

Isso significa um crescimento das vendas de... 200%!

Controle aprimorado do fluxo de trabalho

Em relação aos novos canais, agora você pode controlar exatamente como o fluxo de trabalho da sua solicitação é estruturado. Anteriormente, você enviava uma workflow_id na solicitação, extraído de uma lista predefinida em nosso portal de desenvolvedores. Já na V2, você pode incluir uma carga personalizada para o seu fluxo de trabalho. Por exemplo, se você quiser que a ordem dos canais seja Autenticação Silenciosa -> E-mail -> SMS, a solicitação ficaria assim:

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

Geração de PIN personalizado

Os desenvolvedores também podem enviar um código personalizado para canais que exijam isso (ou seja, todos, exceto o WhatsApp Interativo e a Autenticação Silenciosa). Esse código pode ter entre 4 e 10 caracteres e é alfanumérico. Aqui está um exemplo da carga JSON enviada ao usar um PIN gerado por você mesmo:

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

Mais descanso, por favor

A versão 2 do Verify aproveita melhor os códigos de resposta HTTP. Sim, sim, tudo bem: então não é REST (eu só queria colocar isso no título), mas é um melhor aproveitamento do protocolo HTTP. Aqui estão alguns exemplos:

• Ao iniciar uma solicitação que já foi executada, você recebe um 409 .

• Ao atingir o limite de taxa agora, você recebe um 429

• Uma carga útil inválida para o endpoint de início da solicitação ou para o endpoint de envio do PIN resulta em um 422

• Este é um caso de uso bem interessante: se você digitar um PIN incorreto muitas vezes, acaba recebendo um 410 para indicar que a entidade da solicitação não está mais disponível para quaisquer alterações de estado.

O que VOCÊ vai construir?

Os novos canais que lançamos agora oferecem aos desenvolvedores uma ampla variedade de opções para integrar a autenticação de dois fatores (2FA) em seus sistemas, projetos paralelos e Applications corporativas. A pergunta é: o que você já desenvolveu? Um projeto paralelo apaixonante que se transformou em uma startup com Laravel ou Rails? Uma implantação em uma empresa com arquitetura de microsserviços baseada em Node? Queremos saber! Acesse nosso Slack da Comunidade para conversar conosco.