Verificação Biométrica para Acesso a APIs de IA: Associar Privilégios a uma Pessoa (PT-PT)

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

Essa lacuna é comum na maioria dos produtos e tem consequências numa plataforma de IA, onde os ativos por trás da conta são o acesso ao modelo, créditos e quota. Uma chave de API é um token de portador — quem a detém é a conta. As chaves são partilhadas dentro das equipas, coladas em repositórios, vendidas e tomadas. Seis meses após um onboarding limpo, “esta conta foi verificada” é uma declaração sobre o passado.

A autenticação biométrica fecha essa lacuna. Re-verifica o humano real no momento de uma ação privilegiada — sem documentos, sem palavra-passe, em menos de dois segundos, 0,10 € por autenticação.

Principais pontos

• A verificação no 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 o retrato já armazenado da verificação original do utilizador. Sem documentos, sem palavra-passe.
• Apenas por sessão. Não existe um endpoint /v3/biometric-auth/ — funciona através de uma sessão com workflow_type=BIOMETRIC_AUTHENTICATION.
• O detalhe crítico da implementação: use os mesmos vendor_data da verificação original do utilizador, ou a face armazenada não pode ser recuperada.
• Gatilhos certos: aumentos de quota, concessões de crédito, emissão de novas chaves de API, upgrades de nível, adição de membros de equipa privilegiados e qualquer alerta comportamental da sua camada de tráfego.
• 0,10 € por autenticação, pagamento por sucesso, em menos de dois segundos.

Porque a reautenticação pertence a uma plataforma de IA

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

Partilha 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 para uma rede explorada — e é invisível para qualquer controlo que apenas observe o onboarding.

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

Escala após o facto. A conta que verificou para acesso modesto em janeiro solicita um aumento de quota de 50× em agosto. Nada sobre a verificação de janeiro se refere à solicitação de agosto.

Em todos os três, o estado de verificação da conta não muda e o humano por trás dela não é quem você pensa. Uma palavra-passe, um código único ou um token de sessão não conseguem distinguir esses casos, porque cada um deles é um atacante que detém legitimamente a credencial. Apenas uma verificação biométrica faz a pergunta que importa: a pessoa presente neste momento é 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 vem a imagem de referência — em vez do retrato num documento recém-submetido, usa o retrato já armazenado da verificação anterior do utilizador.

É por isso que não precisa de documentos e por que é rápida e barata o suficiente para se integrar num fluxo de produto normal.

É apenas por sessão

Não existe 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 estiver à procura de um endpoint autónomo na referência da API, é por isso que não o consegue encontrar.

O fluxo

1. Configure um fluxo de trabalho do tipo BIOMETRIC_AUTHENTICATION na consola e anote o 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 utilizador através da sessão retornada — alojada, 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 subscreva session.status.updated e receba o webhook.

O único detalhe que quebra integrações

Use os mesmos vendor_data da verificação original do utilizador.

Esse valor é como o Didit recupera o retrato armazenado para comparação. Um vendor_data novo ou diferente significa que não há face armazenada para comparar, e o fluxo não pode fazer o que pediu. Se precisar de substituir deliberadamente a referência armazenada, 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 vendor_data como um identificador de primeira classe no 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 para as 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 contém um node_id para que os fluxos de trabalho multi-instância possam desambiguar os passos. Cada um é null até que o seu passo 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 limiares e as ações de recusa são configuráveis, para que possa ter um padrão mais rigoroso para uma grande concessão de crédito do que para um aumento de quota de rotina.

O que deve desencadear um step-up

O valor deste controlo depende quase inteiramente do design do gatilho. Demasiados e terá criado um incómodo; poucos e nunca dispara quando importa.

Escala de acesso — aumentos de quota, concessões de crédito, emissão de novas chaves de API, upgrades de nível, passagem para um nível de capacidade que considera sensível.

Alterações na conta — um novo membro de equipa privilegiado, uma alteração do proprietário da faturação, uma alteração do destino de pagamento, uma redefinição de palavra-passe ou MFA.

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

Sinais de ligação — uma sessão que contém DEVICE_RECOVERED_HIGH_CONFIDENCE, ou uma face que corresponde a um utilizador verificado existente, ganhou um step-up, independentemente do que a conta está a pedir.

Dormência mais escala — uma conta inativa por meses que de repente solicita um grande aumento. Não a dormência sozinha; a combinação.

Porque não exigir apenas uma palavra-passe ou um código?

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

Um código único vai para o número de telefone ou endereço registado — que o atacante controla após uma aquisição, e que o partilhador de chaves legítimo simplesmente reencaminha. Uma palavra-passe prova o conhecimento de uma sequência. 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 associar privilégios a uma pessoa, esse é o único fator que responde à verdadeira questão. 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 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 deteta. 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. Os controlos de saída ao nível do modelo e a deteção de tráfego semântico permanecem camadas separadas, e continuam a ser seus.

Casos de uso

Plataformas de API de IA a controlar a escala de quotas, concessões de crédito e emissão de chaves através de uma verificação do humano.

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

Serviços financeiros a reautenticar antes de uma transferência de alto valor ou uma alteração de destino de pagamento.

Marketplaces a reverificar um vendedor antes de uma alteração do método de pagamento — o resultado mais comum de aquisição de conta.

Qualquer plataforma com um fluxo de recuperação a usar a 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 contas.

Perguntas Frequentes

O utilizador precisa de submeter um documento novamente?

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

E se o utilizador nunca foi verificado com o 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; pressupõe uma verificação anterior sob os mesmos vendor_data.

Quanto tempo demora?

Inferência em menos de dois segundos. Do ponto de vista do utilizador, é 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 que serve a deteção de prova de vida. A prova de vida passiva do Didit possui uma avaliação de deteção de ataque de apresentação iBeta Nível 1, e os alertas de ataque facial aparecem nos avisos. Os limiares são configuráveis.

Qual é o custo?

0,10 € por autenticação, pagamento por sucesso, sem mínimo.

Cada login deve exigir isso?

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

Pronto para começar?

Configure um fluxo de trabalho, ligue-o aos seus pontos de escalada e reutilize-o em todo o lado.

• Leia a documentação — Visão geral da Autenticação Biométrica e a API de Sessões.
• Veja o produto — Verificação de Utilizadores.
• Verifique os preços — 0,10 € por autenticação, pagamento por sucesso, sem mínimos.
• Comece gratuitamente — business.didit.me, 500 verificações KYC por mês sem custo.