Crie um login por vídeo sem senha com o Silent Auth e a Video API

A autenticação por vídeo em tempo real sem senha reduz os obstáculos antes do início de uma sessão ao vivo e melhora as taxas de conversão na integração de novos usuários. Senhas e códigos de uso único podem atrasar os usuários. Isso aumenta o risco de abandono das sessões.

APIs da rede Vonage transferem a autenticação para a camada da rede móvel, reduzindo o atrito. Com a Autenticação Silenciosa (Silent Auth)—disponível por meio da Verify API—, o sistema pode verificar automaticamente se o usuário é o proprietário do dispositivo, analisando o tráfego de rede do aparelho, permitindo que as experiências em tempo real sejam iniciadas sem interrupções.

Neste artigo, veremos como o Silent Auth pode ser combinado com a Video API da Vonage para criar um fluxo de integração sem senha para Video em tempo real. Este tutorial explora um padrão de arquitetura reutilizável e inclui trechos de código específicos que destacam as principais decisões de implementação. 

Resumo: Pule esta seção e veja o código funcional deste exemplo no GitHub.

Pré-requisitos

Para acompanhar esta demonstração, você precisará de:

• Um account da API da Vonage.

• Python 3.9 ou versão posterior.

• Android Studio.

• Dispositivo Android físico com um chip SIM habilitado para dados móveis.

Como funciona a autenticação por Video em tempo real sem senha com o Silent Auth

Veja como a autenticação baseada em rede e a integração por Video podem funcionar em conjunto sem estarem intimamente ligadas.

O aplicativo verifica o número de telefone do usuário por meio do Silent Auth quando compatível, com um SMS como alternativa apenas quando necessário. Assim que a verificação for bem-sucedida, um token de Video é gerado e o usuário entra na sessão.

A autenticação é concluída antes do início do Video, para que os usuários tenham uma experiência consistente, independentemente da forma como foram Verified.

Veja como esse fluxo funciona na prática:

Como lidar com casos extremos na prática

A autenticação silenciosa depende da operadora. Se a operadora de celular não oferecer suporte à verificação baseada em rede, a Verify API retorna o código HTTP 412. Uma lista das operadoras de celular compatíveis, por país, está disponível na documentação. As operadoras compatíveis variam de acordo com o país e podem sofrer alterações ao longo do tempo.

Neste aplicativo de demonstração, o recurso de fallback por SMS foi implementado no nível do aplicativo para números não compatíveis. Além do SMS, outros canais de verificação , como RCS e WhatsApp, também estão disponíveis.

Para uso em produção, é necessário o registro no Registro de Rede é obrigatório. Em um ambiente de teste, você pode usar o Operador Virtual sem um dispositivo físico ou registrar um número compatível no Área de Testes do Registro de Rede e usar um dispositivo físico com ele.

Principais considerações sobre a implementação da autenticação silenciosa

Vários detalhes de implementação são importantes ao se trabalhar com o Silent Auth. Juntos, esses elementos permitem que o Silent Auth seja integrado de maneira previsível e com foco na experiência do usuário.

1. A autenticação silenciosa só funciona quando a solicitação de verificação é enviada pela rede da operadora de celular — e não por Wi-Fi. Isso geralmente envolve a integração de uma biblioteca do lado do cliente capaz de forçar a solicitação a ser feita por meio de dados móveis.

2. Nesta implementação, contamos com o comportamento padrão coverage_check=true para determinar o caminho de autenticação. Esse sinalizador instrui a Verify API a avaliar automaticamente se a autenticação silenciosa é compatível com o número fornecido antes de iniciar a verificação. Se o número for compatível, o aplicativo prossegue com a autenticação silenciosa; caso contrário, ele recorre de forma suave à verificação por SMS. Consulte esta documentação sobre a Verificação de Cobertura para obter mais detalhes.

3. Esta implementação utiliza a autenticação silenciosa fluxo síncrono. Nesse modelo, o backend recebe o check_url diretamente da resposta da Verify API, portanto, não é necessário nenhum tratamento de callback no front-end.

Como o backend e o cliente Android funcionam em conjunto

Nesta implementação, o backend em Python é responsável pelo ciclo de vida da verificação utilizando o SDK do Python da Vonage. O cliente Android em Kotlin utiliza o SDK do Vonage Video para Android para a sessão e uma biblioteca Android da operadora para executar o check_url pela rede da operadora.

1. O cliente Android está configurado com uma URL base do backend.

object ServerConfig {
    const val CHAT_SERVER_URL: String = "" // Replace with your backend URL
}

2. O Retrofit usa essa URL base para chamar os endpoints de verificação do backend.

retrofit = Retrofit.Builder()
    .baseUrl(ServerConfig.CHAT_SERVER_URL)
    .addConverterFactory(MoshiConverterFactory.create())
    .client(client)
    .build().also {
        apiService = it.create(APIService::class.java)
    }

3. O cliente pode fazer uma chamada e enviar um número de telefone para o backend.

apiService?.startVerify(StartVerifyRequest(phone_number = phoneNumber))

4. O backend inicia a verificação. Com coverage_check=true (padrão), a Verify API determina se a autenticação silenciosa é compatível com a operadora de destino. 

• Se for compatível, um check_url é retornado.

• Caso não seja compatível, a Verify API responde com o código HTTP 412, e o backend muda explicitamente para o canal SMS.

def verify_start(body: StartVerifyIn):
    try:
        silent_req = VerifyRequest(
            brand="DemoApp",
            workflow=[SilentAuthChannel(to=body.phone_number)],
            coverage_check=True # Checks whether Silent Auth is supported
        )

        verify_resp = client.verify.start_verification(silent_req) # Initiates Silent Auth verification

        return {
            "request_id": verify_resp.request_id,
            "check_url": getattr(verify_resp, "check_url", None),
            "channel": "silent_auth",
        }

    except HttpRequestError as e:
        if e.response and e.response.status_code == 412:
            sms_req = VerifyRequest(
                brand="DemoApp",
                workflow=[SmsChannel(to=body.phone_number)],
            )

            verify_resp2 = client.verify.start_verification(sms_req) # Fallback to SMS verification

            return {
                "request_id": verify_resp2.request_id,
                "channel": "sms",
            }

        raise

5. O backend retorna o canal selecionado, juntamente com os identificadores exigidos pelo cliente.

{
    "channel": "silent_auth",
    "request_id": "...",
    "check_url": "https://..."
} 

• O canal indica ao cliente qual caminho da interface do usuário deve ser seguido (silent_auth ou SMS).

• O `request_id` será necessário posteriormente para confirmar o resultado da verificação.

• O parâmetro `check_url` só está presente quando a opção `silent_auth` é selecionada.

6. Se for `silent_auth`, o Android executa o check_url pela rede da operadora.

O Silent Auth exige que o fluxo de redirecionamento seja executado pela rede da operadora de celular, e não por Wi-Fi. O cliente Android utiliza a biblioteca de solicitações de celular para forçar essa solicitação a ser feita por meio de dados móveis. A implementação completa da função runSilentAuthCheck(), incluindo a execução na rede da operadora e o tratamento da resposta, está disponível no repositório do GitHub.

when (body.channel) {
    "silent_auth" -> runSilentAuthCheck()
    "sms" -> showSmsUi(true)
}

7. O Android envia o código ao backend para confirmar a verificação

O cliente não determina sozinho se a operação foi bem-sucedida. Em vez disso, ele encaminha o código para o backend, que confirma a conclusão por meio da Verify API.

apiService?.confirmVerify(ConfirmVerifyRequest(request_id = rid, code = code))

No backend, isso corresponde a uma chamada de confirmação da Verify API. O backend retorna um status simples para que o cliente possa prosseguir.

def verify_confirm_silent(body: ConfirmVerifyIn):
    verify_response = client.verify.check_code(body.request_id, body.code)
    if isinstance(verify_response, str):
        return {"status": verify_response}

    return {"status": getattr(verify_response, "status", str(verify_response))}

Se o status for “concluído”, a verificação é realizada. Caso contrário, o aplicativo permanece no fluxo de autenticação (nova tentativa / inserir o código novamente).

8. Após a conclusão da verificação, o backend emite um token de Video.

token_options = TokenOptions(
    session_id=os.environ["VONAGE_VIDEO_SESSION_ID"], role="publisher"
)

token = client.video.generate_client_token(token_options)

return {
    "apiKey": os.environ["VONAGE_APPLICATION_ID"],
    "sessionId": os.environ["VONAGE_VIDEO_SESSION_ID"],
    "token": token,
}

9. Em seguida, o cliente Android inicializa o SDK do Video para Android e entra na sessão usando as credenciais fornecidas.

if (status == "completed") {
    initializeSession(apiKey, sessionId, token)
}

Ampliando esse padrão para APIs e plataformas

A implementação apresentada aqui utiliza um backend em Python e o Android para conectar o Silent Auth aos recursos da Video API, mas essa arquitetura pode ser utilizada para muitos outros padrões.

Além da autenticação silenciosa

O Silent Auth é apenas uma das várias APIs de rede. Outros sinais de rede — como Troca de SIM ou Localização do dispositivo — podem ser avaliados antes da concessão de acesso. É possível exigir a validação da troca de SIM antes de permitir o acesso a consultas por vídeo de alto valor. Cada API fornece um sinal de confiança, enquanto o aplicativo decide como agir com base nele.

Verify não é específica do Python

Embora este artigo demonstre a verificação utilizando o SDK do Vonage Verify para Python, o mesmo fluxo do Verify pode ser implementado utilizando outros SDKs do lado do servidor compatíveis, incluindo Node.js, PHP e outros. O padrão arquitetônico permanece inalterado. Também temos um exemplo funcional de autenticação silenciosa (Silent Auth) no fluxo de trabalho com scaffold do Laravel PHP.

Execução baseada em carrier no iOS

Embora este exemplo utilize o Android para execução em rede de operadora, ele também está disponível no iOS. O Silent Auth ainda exige que a solicitação seja executada pela rede da operadora de celular, em vez de Wi-Fi, independentemente da plataforma.

O SDK de vídeo é multiplataforma

A camada de sessão de Video não é específica do Android. O SDK de Video da Vonage está disponível em todas as plataformas, incluindo o iOS, permitindo que o mesmo padrão de “verificar primeiro, depois participar” seja aplicado de maneira consistente.

Conclusão

Neste tutorial, você criou um fluxo de autenticação por vídeo em tempo real sem senha usando o Silent Auth e a Video API da Vonage. Ao separar a verificação da inicialização da sessão, você ganha flexibilidade, segurança e um projeto de autenticação preparado para o futuro.