Autenticação em rede silenciosa: crie um login à prova de fraudes com FastAPI + Kotlin

Proteja seu processo de checkout em Python no FastAPI contra fraudes. 

A fraude não é mais uma tarefa de correção de erros no back-office. É uma decisão tomada em tempo de execução: ou seu código de autenticação a toma em 200 milissegundos, ou os invasores a tomam por você. Este tutorial orienta um engenheiro de back-end Python sobre os dois sinais do lado da operadora que preenchem a lacuna deixada pelo OTP por SMS: a detecção de troca de SIM e a autenticação silenciosa pela rede, ambas integradas a um aplicativo FastAPI funcional que você pode levar ao seu líder técnico ainda hoje. Continue lendo para saber mais sobre fraude e invasão de contas ou pule diretamente para colocar o código em funcionamento usando o README. 

Por que isso é importante: a fraude por invasão de contas já representa um prejuízo anual na casa dos oito dígitos para as fintechs de médio porte e um ônus de suporte de dois dígitos em porcentagem para as equipes de engenharia responsáveis por elas. As duas defesas mais eficazes que você pode integrar a um fluxo de login em Python atualmente são a detecção de troca de SIM (o chip associado a este número foi trocado nos últimos 7 dias?) e a autenticação silenciosa de rede (este é o chip real na rede móvel real para este número, neste momento?). Ambas são executadas no lado da operadora. Ambas são acessíveis por meio das APIs da Rede Vonage. Nenhuma delas exige que o usuário digite nada. 

Próximos passos: Após este tutorial, seu backend FastAPI combina SIM Swap e Silent Auth em uma única rota de login, recorre à Verify por OTP via SMS apenas quando o caminho de rede não pode ser concluído e já vem com as proteções de produção (fallback por tempo limite, padrões de falha fechada, ganchos de observabilidade) necessárias antes de direcionar tráfego real para ele. A prevenção de fraudes de ponta a ponta não é mais um sistema separado a ser integrado; são duas chamadas de API dentro do fluxo de autenticação que você já possui.

O aumento dispendioso das fraudes e das invasões de Accounts

Precisa verificar sua conta bancária? Sem problema! Basta fazer login no portal de internet banking com seu endereço de e-mail e senha. Em seguida — só para ter certeza de que é mesmo você —, uma mensagem de texto contendo uma senha de uso único (OTP) é enviada para o número de celular cadastrado. Se for você mesmo tentando fazer login, presume-se que você tenha esse celular em mãos. Se o código digitado corresponder ao gerado pelo processo de verificação, você será autenticado e terá acesso ao seu dinheiro. 

Mas e se a pessoa que receber essa mensagem de texto não for você? E se alguém roubou seu celular? E se alguém invadiu seu e-mail? E se a tentativa de login tiver sido iniciada por alguém com um bot e uma lista de nomes de usuário e senhas de Accounts comprometidas que está fazendo “credential stuffing”? 

Apropriação de conta é um tipo de fraude que ocorre quando um invasor obtém acesso a uma conta da qual não é o proprietário legítimo. A invasão de conta geralmente é resultado de uma falha de autenticação. A falha de autenticação ocorre quando um invasor engana um sistema, fazendo com que ele reconheça um usuário inválido ou incorreto como legítimo. A falha de autenticação continua sendo um dos dez principais riscos de segurança de aplicativos do Open Web Application Security Project (OWASP) pelo quinto ano consecutivo. 

Fraude por invasão de conta resultou em perdas de quase US$ 13 bilhões em 2023, um aumento em relação aos US$ 11 bilhões registrados em 2022. O custo financeiro, por si só, não é o único risco associado à fraude e às vulnerabilidades na autenticação de aplicativos; os danos à confiança e à reputação da marca são ainda mais onerosos.

Fraud is no longer a back-office cleanup job. 

Embora a fraude provavelmente nunca venha a ser eliminada completamente, existem estratégias que você pode implementar para oferecer níveis adicionais de verificação e segurança e ajudar a evitar a invasão de contas. Nesta postagem do blog, discutiremos essas estratégias e, em seguida, exploraremos um aplicativo de exemplo (cliente Android com servidor FastAPI ) e trechos de código para demonstrar como o o Vonage Verify pode fortalecer seus fluxos de trabalho de autenticação com verificações contra troca de SIM, autenticação silenciosa e recurso a métodos alternativos de verificação. 

Você pode conferir o código do aplicativo de demonstração incluído nesta postagem do blog e colocá-lo em funcionamento seguindo o arquivo README. 

O que é a autenticação de rede silenciosa e por que ela substitui a OTP por SMS

Você já foi vítima de um ataque cibernético? É bem provável que sim. Em dezembro de 2025, o Departamento Federal de Investigação dos Estados Unidos descobriu 630 milhões de senhas comprometidas em vários dispositivos pertencentes a um único hacker. As implicações disso são de longo alcance, mas, acima de tudo, isso exemplifica o quão inseguro o protocolo de nome de usuário e senha se tornou.  

A autenticação multifatorial (MFA) e a autenticação de dois fatores (2FA) oferecem uma camada de proteção contra o roubo de credenciais de login, exigindo a apresentação de mais de um tipo de prova de identidade para obter acesso a um sistema. As senhas de uso único (OTP) enviadas por SMS são uma forma de 2FA que utiliza a prova baseada na posse, do tipo “algo que você possui” que pode comprovar que você é quem diz ser. Devido à onipresença dos celulares, o OTP por SMS é um dos métodos de MFA mais amplamente implementados. 

Infelizmente, devido do uso generalizado do OTP por SMS, os fraudadores desenvolveram estratégias para contornar e comprometer esse método de autenticação multifatorial (MFA), tais como: 

• Interceptação da rede do Sistema de Sinalização 7 (SS7): Uma falha no protocolo no nível da operadora que permite que invasores redirecionem mensagens SMS para si mesmos 

• Troca de SIM: Um invasor utiliza técnicas de engenharia social para fazer com que a operadora reatribua o número da vítima a um novo cartão SIM 

• Phishing: O usuário é induzido a inserir a OTP em uma página de login fraudulenta 

Autenticação silenciosa de rede (SNA) — ou “autenticação silenciosa”, para abreviar — é uma verificação baseada na posse, realizada pela operadora, que redireciona a sessão de dados móveis de um celular pela rede da operadora sem que você precise digitar um código. Isso elimina a dependência de um fator externo (como um invasor) para verificar sua identidade. 

A autenticação silenciosa na rede Verify se o aparelho que está utilizando a sessão de dados móveis é o proprietário do número de telefone — sem enviar um código. Ela funciona redirecionando uma solicitação HTTP verificada pela operadora por meio da própria operadora. Ao contrário da OTP por SMS, ela elimina o vetor de ataque SS7; no entanto, por si só, não oferece proteção contra ataques de troca de SIM — uma verificação de troca de SIM deve ser usada em conjunto com a autenticação silenciosa para mitigar esse risco. Com a Verify API, você pode usar um backend Python FastAPI e um cliente móvel para implementar a autenticação silenciosa e tornar seus aplicativos ainda mais seguros. 

O que é um ataque de troca de SIM e como se proteger contra ele

Um ataque de troca de SIM é um tipo de fraude de apropriação de conta que tem como alvo algumas das vulnerabilidades inerentes ao autenticação multifatorial (MFA) via OTP por SMS. Esse tipo de ataque induz uma operadora de celular a ativar um novo cartão SIM, que a rede da operadora, por sua vez, associa ao número de telefone da vítima. A titularidade do número não muda; o invasor obtém acesso para interceptar SMS recebidos e tráfego de voz vinculado a esse número enquanto a troca não for detectada. Para executar um ataque de troca de SIM, o invasor coleta dados pessoais sobre você por meio de golpes de phishing, listas do mercado negro de dados roubados ou engenharia social. Em seguida, o invasor entra em contato com sua operadora de celular e usa seus dados pessoais para convencer o representante do atendimento ao cliente a ativar um novo cartão SIM mapeado para o seu número. O dispositivo do invasor passa a receber suas mensagens SMS e chamadas recebidas. O invasor nunca se torna o proprietário do número (o faturamento, o contrato e a Account permanecem em seu nome); ele apenas obtém acesso para interceptar na camada de rede até que você ou sua operadora percebam. 

O exemplo mais notável de um ataque bem-sucedido de troca de SIM ocorreu em 2019, quando a conta do CEO do Twitter, Jack Dorsey, foi invadida por meio de SMS fraudulento com OTP de autenticação de duas etapas. O incidente serviu como um forte lembrete de que ninguém está imune à fraude. Além disso, o grupo responsável pelo ataque já tinha um histórico de invasões bem-sucedidas de contas usando métodos semelhantes de troca de SIM por meio de engenharia social. Em outras palavras, os seres humanos continuam sendo o elo mais fraco em qualquer cadeia de segurança. 

Além das medidas práticas que você pode adotar para evitar a troca do chip, como usar códigos PIN, senhas fortes e exclusivas e ter cuidado com as informações que compartilha publicamente, ao desenvolver fluxos de trabalho de autenticação que exijam algum tipo de interação móvel, você pode incluir uma verificação rápida do status do chip do dispositivo. O resultado dessa verificação pode, então, orientar o restante do seu fluxo de trabalho de autenticação, como, por exemplo, recorrer a outra forma de autenticação de duas etapas (2FA). 

Verificar se um cartão SIM foi trocado dentro de um intervalo de tempo configurado pode ajudar a identificar um dispositivo suspeito, acionar métodos alternativos de autenticação e impedir esse tipo comum de ataque. Usando a API Vonage Identity Insights, você pode obter informações sobre um cartão SIM, como a última vez em que ele foi trocado, e, a partir daí, determinar como prosseguir com seu fluxo de autenticação. 

O que é a API Vonage Identity Insights?

A Number Insight API da Vonage fornece informações sobre números de telefone em tempo real diretamente da infraestrutura das operadoras de celular — de forma passiva, sem atritos e impossível de ser falsificada. Especificamente, ela expõe sinais no nível da operadora sobre um número de telefone, incluindo se seu formato é válido, se o cartão SIM foi trocado recentemente e outros indicadores de risco de fraude. Esses sinais podem ser usados para avaliar o nível de risco por trás de uma ação específica — como login, cadastro, recuperação de Account ou transação financeira —, permitindo uma segurança adaptativa que intensifica a proteção exatamente quando e onde for necessário. Para esta postagem do blog, usaremos o insight sobre troca de SIM. 

O recurso de análise de troca de SIM permite determinar se o cartão SIM vinculado a um determinado número de telefone foi trocado recentemente. Ele foi projetado para mitigar o impacto da invasão de contas (ataque de troca de SIM), garantindo que o número de telefone possa ser utilizado em diversos cenários, como a possibilidade de prosseguir com a autenticação de duas fatores (2FA) via SMS ou como um canal de comunicação seguro.

Uma chamada típica ao endpoint do Identity Insights para troca de SIM inclui a seguinte carga útil:

{
    "phone_number": "14040000000",
    "purpose": "FraudPreventionAndDetection",
    "insights": {
        "sim_swap": {
            "period": 240
        }
    }
}

Isso é explicado com mais detalhes a seguir:  

Para saber mais sobre a API e como ela funciona, consulte a documentação do Vonage Identity Insights. 

Uma solicitação bem-sucedida retorna uma 200 OK e uma coleção das informações solicitadas. A resposta também incluirá um request_id: 

{
    "request_id": "aaaaaaaa-bbbb-cccc-dddd-0123456789ab",
    "insights": {
        "sim_swap": {
            "latest_sim_swap_at": "2024-07-08T09:30:27.504Z",
            "is_swapped": true,
            "status": {
                "code": "OK",
                "message": "Success"
            }
        }
    }
}

Com essa resposta, você pode decidir como deseja que seu fluxo de trabalho de verificação prossiga. 

O que é a Verify API? 

Verify API é o produto de autenticação de dois fatores (2FA) de última geração da Vonage. Com a Verify API, você pode autenticar seus usuários e prevenir fraudes por meio de uma API simples e fácil de usar que elimina a complexidade da autenticação de dois fatores em escala global.  

Ela amplia os métodos tradicionais de autenticação ao oferecer suporte a uma gama mais ampla de canais, incluindo canais over-the-top (OTT), como o WhatsApp, além de SMS, voz e e-mail. A API oferece suporte tanto a tokenes da Web JSON (JWT) e autenticação básica. A autenticação básica é mais fácil de começar a usar, mas não oferece suporte a recursos avançados, como ACLs. Você pode usar a autenticação JWT ou a básica, mas não ambas ao mesmo tempo. Saiba mais sobre autenticação na documentação.  

Em linhas gerais, a Verify API segue este fluxo de trabalho: 

1. Um usuário final inicia uma solicitação de autenticação de dois fatores (2FA) em um aplicativo 

2. No back-end, essa solicitação de autenticação de duas etapas (2FA) dá início a uma solicitação à Verify API 

3. A Verify API envia um código de acesso único (OTP) ao usuário final por meio de qualquer canal — ou sequência de canais — que você configurar para seu processo de autenticação (SMS, Voice, WhatsApp, e-mail e outros), oferecendo total flexibilidade para definir o fluxo de verificação que melhor se adapta ao seu caso de uso 

4. O usuário final fornece a OTP ao aplicativo 

5. Isso inicia uma solicitação de Verify para comparar a OTP fornecida pelo usuário final com a OTP gerada pela Vonage 

6. O resultado dessa verificação determina, então, o que acontece a seguir (o usuário final é autenticado, etc.)  

A visual representation of a Verify request flow with summary callbacks.Uma solicitação típica de verificação inicial inclui a seguinte carga útil, em que cada channel na workflow lista define para onde a OTP deve ser enviada:

{"locale": "es-es",  
   "channel_timeout": 180,  
   "client_ref": "myPersonalRef",  
   "code_length": 4,  
   "code": "e4dR1Qz",  
   "brand": "ACME",  
   "template_id": "4ed3027d-8762-44a0-aa3f-c393717413a4",  
   "workflow": [  
      { "channel": "sms",  
         "to": "44770090000"},  
      { "channel": "voice",  
         "to": "44770090000" }  
   ] } 

 Isso é explicado com mais detalhes a seguir:  

Para saber mais sobre a API e como ela funciona, consulte a documentação do Vonage Verify.  

Uma solicitação bem-sucedida retorna um 202 OK para indicar que a solicitação de verificação foi iniciada. A resposta também incluirá um request_id que é necessário para concluir o processo de verificação: 

{ "request_id": "c11236f4-00bf-4b89-84ba-88b25df97315"}   

Ao mesmo tempo, a Vonage envia uma senha de uso único (OTP) ao usuário final por meio do fluxo de trabalho configurado, tentando cada canal na ordem em que estão definidos.  

Assim que o usuário final receber e fornecer a OTP ao aplicativo, será enviada outra solicitação ao verify ponto de extremidade com o request_id como parâmetro de caminho (https://api.nexmo.com/v2/verify/:request_id) e a OTP no corpo da solicitação para a code chave na carga útil. 

Se o código fornecido corresponder ao código gerado e enviado pela Vonage, uma 200 OK resposta é devolvida. 

Como a autenticação silenciosa difere

Autenticação silenciosa utiliza o Módulo de Identidade do Assinante (SIM) do celular para verificar a identidade do usuário sem qualquer intervenção do usuário. Ela compara o número de telefone do usuário com os registros da operadora para confirmar se ele está ativo e é válido. 

Depois que uma solicitação for verificada, você poderá autenticar o usuário continuamente até que a solicitação expire ou seja cancelada pelo usuário. 

Para incluir a Autenticação Silenciosa como parte do seu processo de verificação, adicione-a como um channel à workflow lista na carga útil da sua solicitação. Observe que silent_auth deve ser listado em primeiro lugar, pois o fluxo de trabalho é executado na ordem em que está definido: 

"workflow": [
    {
        "channel": "silent_auth",
        "to": "44770090000",
        "redirect_url": "https://acme-app.com/sa/redirect",
        "check_coverage": "true"
    },
    {
        "channel": "sms",
        "to": "44770090000"
    },
    {
        "channel": "voice",
        "to": "44770090000"
    }
]

Quando o silent_auth canal for incluído, a resposta contém um check_url além do request_id: 

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

O valor de check_url é a URL que GET é então executada por meio de dados móveis no lado do cliente. É importante observar que a autenticação silenciosa depende de uma resposta GSM verificada do dispositivo para comprovar suas credenciais, a qual não é enviada se o usuário estiver conectado a uma rede Wi-Fi. Portanto, o usuário deve acionar a solicitação de autenticação usando dados móveis. (Analisaremos mais detalhadamente como o SDK da Vonage para Android pode forçar uma conexão móvel quando chegarmos à parte do cliente.) 

Se o cliente conseguir realizar com sucesso uma GET solicitação na URL, a Vonage responde com o request_id e um code. 

Esse código é então verificado em uma chamada ao verify ponto de extremidade e, se corresponder à OTP gerada pela Vonage, então um 200 OK é retornado com "status": "complete".  

Criação de um sistema de prevenção de fraudes de ponta a ponta com Python, Kotlin e Vonage

O aplicativo de exemplo apresentado nesta postagem do blog demonstra um fluxo mínimo de autenticação que poderia ser usado como uma etapa adicional para a autenticação multifatorial (MFA). Você pode encontrar o código na GitHub da Comunidade Vonage. O cliente Android baseado em Kotlin interage com um servidor backend escrito com FastAPI, utilizando as APIs do Vonage Insights e da Verify API para definir e executar um fluxo de trabalho de autenticação. 

O aplicativo executa a seguinte sequência: 

1. O usuário final é recebido com uma tela de verificação que solicita que ele insira seu número de telefone. 

2. O envio de um número de telefone aciona uma solicitação POST ao servidor de back-end, dando início a uma sequência de etapas de verificação. 

3. O backend faz uma chamada ao endpoint do Insights para verificar se o SIM foi trocado dentro de um determinado limite. 

4. Se o cartão SIM tiver sido trocado recentemente ou se não for possível determinar essas informações, ele é sinalizado. 

   1. Um chip (SIM) sinalizado pode indicar que um dispositivo está comprometido. Isso afeta a confiabilidade de outras formas de verificação baseadas em dispositivos móveis; por isso, o aplicativo recorre ao endereço de e-mail cadastrado para o número de telefone fornecido e envia uma senha de uso único (OTP) para esse endereço por meio da Verify API. 

   2. Se o usuário final receber e fornecer uma OTP que corresponda à OTP gerada pela Vonage, ele será verificado; caso não haja correspondência, o usuário final não será verificado. 

5. Se o cartão SIM não tiver sido trocado recentemente, o fluxo de trabalho prossegue com a autenticação silenciosa. 

6. Se a autenticação silenciosa falhar ou não for compatível com a rede da operadora de celular, o aplicativo recorre ao OTP por SMS. 

   1. Se o usuário final receber e fornecer uma OTP que corresponda à OTP gerada pela Vonage, ele será verificado; caso não haja correspondência, o usuário final não será verificado. 

7. Se a autenticação silenciosa for concluída com sucesso, o usuário final é verificado.  

Os pré-requisitos, a configuração do ambiente e as etapas para executar este código podem ser encontrados no arquivo README no GitHub. Abordaremos as partes mais importantes do código em detalhes a seguir. 

Utilizando o FastAPI e o SDK do Vonage para Python para definir o servidor de back-end 

Para ajudar a estabelecer uma separação de responsabilidades, definimos um conjunto de funções que interagem com o Vonage em um arquivo chamado vonage_handlers.py. 

Inicializando os clientes da Vonage

Neste aplicativo de exemplo, utilizamos as APIs do Identity Insights e da Verify API. Como elas possuem endpoints ligeiramente diferentes, criaremos dois clientes para lidar com isso. Em ambos os casos, VONAGE_APPLICATION_ID e VONAGE_PRIVATE_KEY_PATH são fornecidos pela Vonage quando você cria uma aplicação. A configuração completa desta aplicação está descrita no repositório README. 

verify_client = Vonage(
    Auth(
        application_id=os.environ["VONAGE_APPLICATION_ID"],
        private_key=os.environ["VONAGE_PRIVATE_KEY_PATH"],
    )
)

identity_insights_client = Vonage(
    Auth(
        application_id=os.environ["VONAGE_APPLICATION_ID"],
        private_key=os.environ["VONAGE_PRIVATE_KEY_PATH"],
    ),
    http_client_options={"api_host": "api-eu.vonage.com"},
)

Verificação de troca de cartão SIM

Primeiro, verificamos o status do chip associado ao número fornecido pelo usuário final ao cliente e retornamos True, False, ou None: 

def check_sim_swap(phone: str) -> bool | None:
    """
    Returns True if SIM was swapped, False if not, None if carrier doesn't permit check.
    """
    insights_request = IdentityInsightsRequest(
        phone_number=phone,
        purpose="FraudPreventionAndDetection",
        insights=InsightsRequest(
            format=EmptyInsight(), sim_swap=SimSwapInsight(period=240)
        ),
    )
    return identity_insights_client.identity_insights.requests(
        insights_request
    ).insights.sim_swap.is_swapped

Essa função faz uma chamada ao endpoint do Identity Insights e retorna ao cliente as informações sobre troca de SIM (SIM Swap) referentes ao número fornecido pelo usuário final. 

Inicializar o processo de verificação de autenticação silenciosa

Inicializamos o fluxo de trabalho de verificação com a start_silent_auth função: 

def start_silent_auth(phone: str) -> dict:
    """
    Starts Silent Auth verification.
    Returns channel, request_id, and check_url.
    Raises HttpRequestError with 412 if Silent Auth unavailable.
    """
    request = VerifyRequest(
        brand="DemoApp", workflow=[SilentAuthChannel(to=phone)], coverage_check=True
    )
    response: StartVerificationResponse = verify_client.verify.start_verification(
        request
    )
    return {
        "channel": "silent_auth",
        "request_id": response.request_id,
        "check_url": response.check_url,
    }

Incluímos o coverage_check parâmetro para verificar, de forma síncrona, se a rede de destino do usuário final é compatível com a Autenticação Silenciosa. Caso não seja compatível, a Vonage retorna uma 4xx resposta. Essa verificação inicial evita qualquer atraso que possa resultar de fluxos de redirecionamento desnecessários. Em vez de fazer várias GET tentativas, seu aplicativo pode recorrer a outro método de verificação caso a Autenticação Silenciosa não seja compatível com a rede da operadora do usuário final. Isso pode resultar em uma melhor experiência do usuário. 

Se a rede do usuário final for compatível com a Autenticação Silenciosa e a GET solicitação na check_url fornecido pela Vonage for bem-sucedida, então um request_id e code é retornado. Esse código é verificado em outra função. 

Recurso de reserva para métodos alternativos de OTP

Dependendo dos resultados da verificação de troca de SIM e da tentativa de autenticação silenciosa, talvez seja recomendável recorrer a um método alternativo de OTP. 

No caso de um cartão SIM trocado, talvez seja melhor recorrer a um método de OTP que não dependa exclusivamente de um dispositivo móvel. Se um cartão SIM tiver sido trocado de forma fraudulenta, a autenticação silenciosa pode não ser mais confiável. A troca do chip nem sempre é resultado de um roubo de conta, mas é melhor prevenir do que remediar; por isso, talvez seja melhor enviar a OTP para outro local. 

Na start_email função, usamos a Verify API para iniciar um processo de verificação por e-mail:

def start_email(phone: str, email: str) -> dict:
    """
    Starts email OTP verification.
    Returns request_id.
    """
    request = VerifyRequest(
        brand="DemoApp",
        workflow=[EmailChannel(to=email)],
    )
    response = verify_client.verify.start_verification(request)
    return {"request_id": response.request_id}

Se o cartão SIM tiver não fosse trocado, mas a operadora do usuário final não for compatível ou a autenticação silenciosa falhar, recorremos à senha de uma única uso (OTP) por SMS: 

def start_sms(phone: str) -> dict:
    """
    Starts SMS OTP verification.
    Returns channel and request_id.
    """
    logger.info(f"Starting SMS fallback with: {phone}")
    request = VerifyRequest(
        brand="DemoApp",
        workflow=[SmsChannel(to=phone)],
    )
    response = verify_client.verify.start_verification(request)
    return {"channel": "sms_otp", "request_id": response.request_id}

Verificação do OTP

Por fim, fazemos uma chamada para o verify ponto de extremidade usando o request_id e fornecendo o código fornecido pelo usuário final por e-mail ou SMS (OTP) ou pelo lado do cliente como resultado da autenticação silenciosa: 

def check_code(request_id: str, code: str) -> bool:
    """
    Validates OTP code with Vonage. Returns True if verified.
    """
    response = verify_client.verify.check_code(request_id, code)
    return {"verified": True, "status": response.status}

O servidor de back-end: integrando tudo com o FastAPI

FastAPI é um framework web de alto desempenho para a criação de APIs de serviços baseadas em HTTP em Python. O que diferencia o FastAPI de outros frameworks web em Python é sua estreita integração com o Pydantic, uma biblioteca de validação de dados para Python. Esse acoplamento permite que o FastAPI valide, serialize e deserialize dados. Isso oferece um método mais declarativo para especificar a estrutura e os tipos de dados para solicitações recebidas, como corpos de HTTP, e respostas enviadas. O FastAPI também gera automaticamente especificações OpenAPI. Todas essas funcionalidades combinadas o tornam especialmente adequado para APIs REST modernas, desenvolvimento de microsserviços e Applications que exigem funcionalidade em tempo real. 

O arquivo main.py contém nossas rotas do FastAPI. 

No aplicativo de exemplo, recorremos a uma OTP por e-mail no caso de troca do cartão SIM. Em um aplicativo pronto para implantação em produção, esse e-mail é fornecido pelo usuário final no momento do cadastro da conta e armazenado em um banco de dados. Em nosso aplicativo de exemplo mínimo, você fornece um e-mail de teste que é armazenado na memória. Esse armazenamento na memória simula um banco de dados usando variáveis de ambiente que você fornece no .env arquivo: 

USER_EMAIL_STORE = {os.environ["USER_PHONE_NUMBER"]: os.environ["USER_EMAIL"]}

A /verification rota realiza uma verificação de troca de SIM e, dependendo do status do SIM, inicia um fluxo de trabalho de verificação de autenticação silenciosa. Se sim_swapped for False mas a autenticação silenciosa resultar em um 412 (o que significa que a rede do usuário final não é compatível), então recorremos ao OTP por SMS: 

@app.post("/verification")
async def start_verification(req: VerificationRequest):
    """
    Starts the verification process:
    - Check if SIM is swapped-- if sim_swapped: True, fallback to email
    - If sim_swapped: False, begin Silent Authentication
    """
    phone = req.phone
    logger.info(f"Beginning authentication process for: {phone}")

    try:
        sim_swapped = check_sim_swap(phone)
        logger.info(f"Swap status for {phone}: {sim_swapped}")

        if sim_swapped or sim_swapped is None:
            logger.info("SIM swap flagged, stepping up to email")
            return {"channel": "email_stepup", "request_id": None}

        return start_silent_auth(phone)

    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

@app.post("/fallback-sms")
async def fallback_sms(req: VerificationRequest):

    phone = req.phone
    # Uncomment the line below and comment out the line above
    # to test this app with a Virtual Operator number and receive an OTP
    # to a real phone number
    # phone = os.environ["USER_PHONE_NUMBER"]

    logger.info(f"SMS fallback requested, sending to: {phone}")
    try:
        return start_sms(phone)
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

Se sim_swapped for True, retornamos {"channel": "email_stepup", "request_id": None} o que fará com que o cliente chame a /send-email-otp: 

@app.post("/send-email-otp")
async def send_email_otp(req: VerificationRequest):
    """
    Starts the verification process via email:
    - Check if there is a stored email -- if no email, raise exception
    - If there is an email, begin verification
    """
    phone = req.phone

    logger.info(f"Stepping up to email for verification process for: {phone}")
    email = USER_EMAIL_STORE.get(phone)
    logger.info(f"Getting email address from simulated user database: {email}")

    if not email:
        raise HTTPException(status_code=404, detail="No email on file for this number")

    logger.info(f"Beginning email verification for: {email}")
    try:
        return start_email(phone, email)
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

Por fim, utilizamos a /check-code route para concluir o processo de autenticação: 

@app.post("/check-code")
async def verify_code(req: CheckCodeRequest):
    request_id = req.request_id
    code = req.code
    logger.info(f"Checking code for request_id: {request_id} with code: {code}")
    try:
        response = check_code(request_id, code)
        logger.info("Verification success!")
        return response
    except Exception as e:
        logger.info("Verification failure")
        return {"verified": False, "status": str(e)}

Utilizando o Client SDK do Vonage para Android para definir o cliente

O cliente deste aplicativo de exemplo foi desenvolvido com Kotlin e utiliza bibliotecas modernas, como OkHttp e Kotlin Coroutines , juntamente com o Jetpack Compose para a interface do usuário. O código completo pode ser encontrado no repositório do GitHub. O cliente oferece uma interface móvel minimalista. 

Ele também utiliza o SDK do Vonage para Android para executar a etapa de autenticação silenciosa do fluxo de trabalho de verificação no ApiClient.kt arquivo: 

    suspend fun checkSilentAuth(url: String): String = withContext(Dispatchers.IO) {
        val params = VGCellularRequestParameters(
            url = url,
            headers = mapOf(),
            queryParameters = mapOf(),
            maxRedirectCount = 10
        )

        Log.d("DemoApp", "Attempting Silent Authentication ...")

        val response = VGCellularRequestClient.getInstance()
            .startCellularGetRequest(params, false)

        val sdkError = response.optString("error", "")
        if (sdkError.isNotEmpty()) {
            throw SilentAuthUnavailableException("SDK error: $sdkError")
        }

        val httpStatus = response.optInt("http_status", -1)
        if (httpStatus !in 200..299) {
            throw SilentAuthUnavailableException("HTTP $httpStatus")
        }

        val code = response.optJSONObject("response_body")?.optString("code", null)
        if (code.isNullOrBlank()) throw SilentAuthUnavailableException("Silent auth response missing 'code'")

        code
    }

Esta linha utiliza a Biblioteca do Cliente Vonage para Android para forçar uma conexão móvel ao fazer uma GET solicitação na check_url gerado pela Vonage quando iniciamos o processo de verificação: 

val response = VGCellularRequestClient.getInstance()
    .startCellularGetRequest(params, false)

Se a GETsolicitação for bem-sucedida, um código é retornado e enviado ao backend para verificação. 

Prevenção de fraudes de ponta a ponta

Siga o README para obter o código necessário para colocar o aplicativo de exemplo em funcionamento e testá-lo. Certifique-se de configurar o Network Registry Playground para que você possa começar a testar os Recursos de Rede imediatamente. Este aplicativo de exemplo funciona melhor com um dispositivo ativo; no entanto, há algumas ressalvas a serem lembradas: dependendo da sua operadora de celular, a API Identity Insights e o canal de verificação de Autenticação Silenciosa podem não funcionar. Verifique a documentação de cobertura da Vonage para verificar se sua operadora é compatível. Você também pode usar o Operadora Virtual da Vonage para testar diferentes cenários.

Em resumo

A fraude e a invasão de contas são problemas onerosos — não apenas financeiramente, mas também em termos da confiança na marca e da credibilidade do desenvolvedor, que levam anos para serem construídas. Embora amplamente adotada, a OTP por SMS tradicional apresenta vulnerabilidades bem documentadas: falhas no protocolo SS7, ataques de troca de SIM e phishing — todos esses fatores comprometem sua confiabilidade como segundo fator de autenticação isolado. 

Nesta postagem do blog, exploramos uma abordagem em camadas para a autenticação que enfrenta essas vulnerabilidades de frente: 

• Detecção de troca de SIM: Usando a API Vonage Identity Insights, você pode verificar se um número de telefone foi recentemente reatribuído a um novo cartão SIM e usar essa informação para tomar decisões mais inteligentes sobre como proceder com a autenticação. Uma reatribuição recente é um sinal de alerta que justifica a mudança para um canal de verificação mais confiável. 

• Autenticação silenciosa: Em vez de depender do usuário para receber e inserir um código, o canal de autenticação silenciosa da Verify API verifica a identidade de um dispositivo diretamente pela rede da operadora. Sem código, sem entrada do usuário, sem possibilidade de interceptação. 

• Soluções alternativas elegantes: Não existe um único método que funcione em todas as situações. Quando a autenticação silenciosa não é suportada por uma operadora, o aplicativo recorre à OTP por SMS. Quando é detectada uma troca de SIM, o aplicativo passa a utilizar a OTP por e-mail — um canal que não está vinculado ao dispositivo potencialmente comprometido. 

O aplicativo de exemplo demonstra como essas três estratégias podem ser combinadas em um fluxo de trabalho de autenticação coeso e prático, utilizando o SDK do Vonage para Python e o SDK do Vonage para Android. 

Provavelmente, a fraude nunca será totalmente eliminada, mas, com as ferramentas certas e uma abordagem cuidadosa e em camadas, é possível tornar significativamente mais difícil para os invasores terem sucesso — e significativamente mais fácil para os usuários legítimos terem acesso. 

Leituras complementares e recursos

• Documentação da Verify API do Vonage: A Verify API é nosso produto de autenticação de dois fatores (2FA) de última geração.

• Documentação da API do Vonage Identity Insights: A Number Insight API da Vonage fornece informações em tempo real sobre a validade, acessibilidade e status de roaming de um número de telefone, além de indicar como formatar o número corretamente em seu aplicativo.

• Área de Testes do Registro de Rede: O Playground permite que os desenvolvedores comecem a usar os Recursos de Rede enquanto aguardam a aprovação de seu perfil de negócios pelas operadoras.

• Integração digital bancária com autenticação silenciosa: Reduza os atritos e as desistências durante a integração digital, priorizando a autenticação silenciosa da Verify API em vez da senha de uso único (OTP).

P1. O que é autenticação silenciosa em rede? 

A autenticação silenciosa de rede (SNA) é um método do lado da operadora que verifica o número de telefone do usuário, encaminhando a sessão de dados móveis do dispositivo pela rede da operadora. Nenhum código é enviado ao usuário e não é necessária nenhuma ação por parte dele. Isso elimina os vetores de ataque de interceptação SS7 e de troca de SIM que a OTP por SMS deixa expostos.  

P2. Qual é a diferença entre a autenticação silenciosa na rede e a detecção de troca de SIM? 

 A autenticação silenciosa de rede verifica se o SIM atualmente ativo na sessão de dados móveis é aquele que a operadora associa ao número de telefone que está sendo verificado. A detecção de troca de SIM verifica se um novo SIM (físico ou eSIM) foi ativado recentemente e mapeado para esse número na operadora. A propriedade do número em si (faturamento, contrato, Account) não muda em uma troca de SIM; o invasor obtém acesso para interceptação na camada de roteamento da rede, não a propriedade legal. A SNA confirma que a vinculação atual entre o SIM e o número permanece inalterada, e a detecção de troca de SIM sinaliza se essa vinculação foi atualizada recentemente. Combinar ambas as verificações no mesmo fluxo de login permite identificar invasores que já convenceram uma operadora a emitir um SIM mapeado para o número da vítima antes de eles tentarem fazer o login. 

P3. A autenticação silenciosa de rede funciona em redes Wi-Fi? 

Não. A autenticação de rede silenciosa requer uma sessão ativa de dados móveis, pois o fluxo da CAMARA é roteado pela rede da operadora, e não pela internet. Dispositivos conectados apenas por Wi-Fi, tablets sem cartão SIM e computadores de mesa não conseguem concluir o redirecionamento de dados móveis. É necessário implementar um plano alternativo — a Verify API da Vonage com OTP por SMS ou voz é o plano alternativo padrão e pode ser acionada a partir do mesmo cliente do SDK Python da Vonage. 

P4. Quais bibliotecas do Python são necessárias para a autenticação de rede silenciosa com a Vonage? 

Você precisará do Vonage (o SDK do Vonage para Python no PyPI), do fastapi, do uvicorn e do python-dotenv. Para ambiente de produção, adicione o redis-py para armazenar os auth_request_ids entre as rotas de iniciação e de retorno de chamada, e o slowapi ou um middleware personalizado para limitar a taxa de acesso ao endpoint de autenticação.