Autenticação Biométrica para APIs de IA: Vinculando Privilégios a uma Pessoa (PT-BR)

A verificação no onboarding prova quem criou uma conta. Não prova nada sobre quem a está usando agora.

Essa lacuna é comum na maioria dos produtos e impactante em uma plataforma de IA, onde os ativos por trás da conta são acesso a modelos, créditos e cota. Uma chave de API é um token de portador — quem a detém é a conta. As chaves são compartilhadas entre equipes, coladas em repositórios, vendidas e assumidas. Seis meses após um onboarding limpo, "esta conta foi verificada" é uma afirmação sobre o passado.

A autenticação biométrica fecha essa lacuna. Ela reverifica o humano real no momento de uma ação privilegiada — sem documentos, sem senha, em menos de dois segundos, $0.10 por autenticação.

Principais pontos

• A verificação de onboarding é um instantâneo. A autenticação biométrica é uma verificação no momento em que importa.
• Prova de vida mais correspondência facial com a foto já armazenada da verificação original do usuário. Sem documentos, sem senha.
• Apenas sessão. Não existe um endpoint /v3/biometric-auth/ — ele é executado através de uma sessão com workflow_type=BIOMETRIC_AUTHENTICATION.
• O detalhe crítico de implementação: use o mesmo vendor_data da verificação original do usuário, ou o rosto armazenado não poderá ser recuperado.
• Gatilhos corretos: aumentos de cota, concessões de crédito, emissão de novas chaves de API, atualizações de nível, adição de membros de equipe privilegiados e qualquer alerta comportamental da sua camada de tráfego.
• $0.10 por autenticação, pague por sucesso, em menos de dois segundos.

Por que a reautenticação pertence a uma plataforma de IA

Três modos de falha tornam o instantâneo de onboarding insuficiente.

Compartilhamento e revenda de chaves. Uma chave emitida para um desenvolvedor verificado pode acabar em qualquer lugar. A conta permanece verificada; a pessoa que a usa não é a pessoa que verificou. Este é o mecanismo pelo qual uma conta legitimamente verificada se torna um ponto de entrada em uma rede fraudulenta — e é invisível para qualquer controle que apenas observe o onboarding.

Tomada de conta. As credenciais são obtidas por phishing ou preenchimento de credenciais, e o invasor herda uma conta verificada com reputação estabelecida e limites elevados. Uma conta verificada é um alvo de tomada de conta mais atraente, não menos atraente.

Escalonamento posterior. A conta que foi verificada para acesso modesto em janeiro solicita um aumento de cota de 50 vezes em agosto. Nada sobre a verificação de janeiro se refere à solicitação de agosto.

Nos três casos, o status de verificação da conta permanece inalterado e o humano por trás dela não é quem você pensa. Uma senha, um código de uso único ou um token de sessão não podem distinguir esses casos, porque cada um deles é um invasor que detém legitimamente a credencial. Apenas uma verificação biométrica faz a pergunta que importa: a pessoa presente agora é a pessoa que verificou?

Como funciona

A Autenticação Biométrica reutiliza os mesmos componentes LivenessV3 e FaceMatchV3 do fluxo de identidade regular. A única diferença é de onde a imagem de referência vem — em vez do retrato em um documento recém-enviado, ela usa o retrato já armazenado da verificação anterior do usuário.

É por isso que não precisa de documentos, e por que é rápido e barato o suficiente para ser inserido em um fluxo de produto normal.

É apenas de sessão

Não há um endpoint dedicado /v3/biometric-auth/. A autenticação é entregue através de uma sessão cujo fluxo de trabalho é configurado para isso — workflow_type=BIOMETRIC_AUTHENTICATION. Se você estiver procurando por um endpoint autônomo na referência da API, é por isso que não consegue encontrá-lo.

O fluxo

1. Configure um fluxo de trabalho do tipo BIOMETRIC_AUTHENTICATION no console e anote seu workflow_id.
2. Crie uma sessão:

curl -X POST 'https://verification.didit.me/v3/session/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "workflow_id": "YOUR_BIOMETRIC_AUTH_WORKFLOW_ID",
    "vendor_data": "acct_8842",
    "callback": "https://yourplatform.example/auth/complete"
  }'

1. Envie o usuário através da sessão retornada — hospedada ou incorporada com qualquer um dos SDKs gratuitos.
2. Obtenha a decisão:

curl -X GET 'https://verification.didit.me/v3/session/{sessionId}/decision/' \
  -H 'x-api-key: YOUR_API_KEY'

Ou assine session.status.updated e receba o webhook.

O único detalhe que quebra integrações

Use o mesmo vendor_data da verificação original do usuário.

Esse valor é como a Didit recupera o retrato armazenado para comparação. Um vendor_data novo ou diferente significa que não há rosto armazenado para comparar, e o fluxo não pode fazer o que você pediu. Se você precisar substituir a referência armazenada deliberadamente, passe portrait_image explicitamente — mas o caminho normal é um vendor_data estável por conta, definido no onboarding e reutilizado para sempre.

Este é o argumento para tratar o vendor_data como um identificador de primeira classe em seu próprio esquema desde o primeiro dia. Também é o que faz com que os resultados da Pesquisa Facial se mapeiem de forma limpa em suas contas.

Lendo o resultado

Os resultados chegam em liveness_checks e face_matches. Ambos são sempre arrays — nunca objetos singulares — e cada item carrega um node_id para que fluxos de trabalho multi-instância possam desambiguar as etapas. Cada um é null até que sua etapa tenha produzido dados.

Os avisos incluem LOW_LIVENESS_SCORE, alertas de ataque facial, correspondências de lista de bloqueio e baixa similaridade de correspondência facial. Os limites e as ações de recusa são configuráveis, para que você possa ter uma barra mais rigorosa para uma grande concessão de crédito do que para um aumento rotineiro de cota.

O que deve acionar um step-up

O valor desse controle depende quase inteiramente do design do gatilho. Muitos e você criou um incômodo; poucos e ele nunca dispara quando importa.

Escalonamento de acesso — aumentos de cota, concessões de crédito, emissão de novas chaves de API, atualizações de nível, mudança para um nível de capacidade que você considera sensível.

Alterações de conta — um novo membro de equipe privilegiado, uma mudança de proprietário de cobrança, uma alteração de destino de pagamento, uma redefinição de senha ou MFA.

Alertas comportamentais — o gatilho de maior valor. Quando sua própria camada de tráfego sinaliza uma conta para consulta concentrada ou um padrão em forma de destilação, um step-up biométrico faz a única pergunta que a camada de tráfego não pode: o humano verificado ainda é quem está operando esta conta? Um acerto estreita a interpretação. Uma falha ou um abandono é em si um forte sinal.

Sinais de vinculação — uma sessão que carrega DEVICE_RECOVERED_HIGH_CONFIDENCE, ou um rosto que correspondeu a um usuário verificado existente, ganhou um step-up independentemente do que a conta está solicitando.

Inatividade mais escalonamento — uma conta inativa por meses que de repente solicita um grande aumento. Não apenas a inatividade; a combinação.

Por que não apenas exigir uma senha ou um código?

Porque todo fator convencional é uma credencial de portador, e o modelo de ameaça aqui é um invasor que detém a credencial.

Um código de uso único vai para o número de telefone ou endereço registrado — que o invasor controla após uma tomada de conta, e que o legítimo compartilhador de chaves simplesmente encaminha. Uma senha prova o conhecimento de uma string. Uma chave de hardware prova a posse de um objeto, que pode ser entregue com a chave.

Uma correspondência facial com prova de vida prova que um ser humano específico está presente neste momento. Para vincular privilégios a uma pessoa, esse é o único fator que responde à pergunta real. A $0.10 e em menos de dois segundos, também é barato o suficiente para ser usado em gatilhos reais, em vez de ser guardado para emergências.

O que ele não faz também vale a pena mencionar. Reautenticar o humano por trás de uma conta não impede a extração de modelos e não a detecta. Um desenvolvedor verificado ainda pode usar indevidamente o acesso que possui. Isso fecha a lacuna entre "esta conta foi verificada uma vez" e "este humano está aqui agora" — uma lacuna estreita e real. Controles de saída em nível de modelo e detecção de tráfego semântico permanecem camadas separadas, e elas continuam sendo suas.

Casos de uso

Plataformas de API de IA controlando o escalonamento de cotas, concessões de crédito e emissão de chaves por trás de uma verificação do humano.

Produtos de agente e automação exigindo um step-up antes que um agente receba uma nova capacidade ou um limite de gastos seja aumentado.

Serviços financeiros reautenticando antes de uma transferência de alto valor ou uma mudança de destino de pagamento.

Marketplaces reverificando um vendedor antes de uma mudança de método de pagamento — o ganho mais comum de tomada de conta.

Qualquer plataforma com um fluxo de recuperação usando reautenticação biométrica em vez de perguntas baseadas em conhecimento, que são o elo mais fraco na maioria dos designs de segurança de conta.

Perguntas frequentes

O usuário precisa enviar um documento novamente?

Não. Esse é o ponto. A verificação é feita contra o retrato já armazenado da verificação original — prova de vida mais correspondência facial, sem documentos.

E se o usuário nunca foi verificado com a Didit?

Então não há retrato armazenado e não há nada para autenticar. A Autenticação Biométrica é uma primitiva de reverificação; ela pressupõe uma verificação anterior sob o mesmo vendor_data.

Quanto tempo leva?

Inferência em menos de dois segundos. Do ponto de vista do usuário, é uma selfie e um momento.

Pode ser executado dentro da nossa própria interface?

Sim. Os SDKs web, iOS, Android, React Native e Flutter são todos gratuitos, e o White Label ($0.20) remove a marca Didit.

E se alguém segurar uma foto ou um vídeo do proprietário da conta?

Para isso serve a detecção de prova de vida. A prova de vida passiva da Didit possui uma avaliação de detecção de ataque de apresentação iBeta Nível 1, e alertas de ataque facial aparecem nos avisos. Os limites são configuráveis.

Quanto custa?

$0.10 por autenticação, pague por sucesso, sem mínimo.

Todo login deveria exigir isso?

Não. O login é o gatilho errado — ele dispara constantemente e na maioria das vezes sem motivo. Anexe-o ao escalonamento de privilégios e aos alertas, onde o custo de estar errado é alto e a frequência é baixa.

Pronto para começar?

Configure um fluxo de trabalho, conecte-o aos seus pontos de escalonamento e reutilize-o em todos os lugares.

• Leia a documentação — Visão geral da Autenticação Biométrica e a API de Sessões.
• Veja o produto — Verificação de Usuário.
• Verifique os preços — $0.10 por autenticação, pague por sucesso, sem mínimos.
• Comece grátis — business.didit.me, 500 verificações KYC por mês sem custo.