Autenticação Multimétodo em APIs de Assinatura: Biometria, OTP, Clickwrap e Certificados Digitais
Quando uma aplicação solicita que um usuário assine um documento eletronicamente, surge uma questão fundamental: como garantir que a pessoa que está assinando é realmente quem diz ser? A resposta não é única. Existe um espectro completo de métodos de verificação de identidade, cada um com níveis distintos de garantia (assurance), custo de implementação e impacto na experiência do usuário.
Em um cenário B2B onde APIs de assinatura digital são integradas a sistemas corporativos — ERPs, CRMs, plataformas de onboarding, sistemas jurídicos — a escolha do método de autenticação do signatário é uma decisão arquitetural com implicações legais, de segurança e de conversão. Um contrato de locação residencial não exige o mesmo nível de verificação que uma escritura pública ou um contrato de financiamento imobiliário.
Este artigo é um guia técnico aprofundado sobre os quatro principais métodos de autenticação de signatários disponíveis via API: clickwrap, OTP (One-Time Password), biometria facial e certificados digitais ICP-Brasil A1. Para cada método, vamos cobrir o funcionamento, o nível de assurance, exemplos de implementação via API e os cenários de uso ideais. Ao final, apresentamos uma matriz de decisão que ajuda a escolher — ou combinar — métodos de acordo com o tipo de documento, risco e requisitos legais.
Se você ainda não conhece os fundamentos das APIs de assinatura digital, recomendamos começar pelo artigo O que é uma API de Assinatura Digital. Para entender o fluxo completo de autenticação da aplicação (OAuth 2.0), veja OAuth 2.0 para APIs de Assinatura.
https://api.signdocs.com.br (HML: https://api-hml.signdocs.com.br), autenticação OAuth2 client_credentials com Bearer JWT no header Authorization, todos os endpoints sob o prefixo /v1/, corpo em application/json e erros no formato RFC 7807 (application/problem+json). O recurso principal criado para cada assinatura é uma Transação (POST /v1/transactions); para fluxos com mais de um signatário sobre um mesmo documento, existe ainda o wrapper de Envelope (POST /v1/envelopes).
customSteps descritos neste artigo também funcionam na API de Assinatura Expressa (POST /v1/signing-sessions), que encapsula criação de transação + upload de documento + página hospedada em uma única chamada. O modelo policy é idêntico — muda apenas o endpoint, que retorna url + clientSecret para redirecionar o signatário.
O Espectro de Verificação de Identidade
A verificação de identidade em assinaturas digitais pode ser entendida como um espectro que vai de baixa garantia (low assurance) até alta garantia (high assurance). Cada nível agrega mais evidências sobre a identidade do signatário, mas também aumenta a fricção no processo de assinatura.
| Nível | Método | Assurance | Fricção UX | Base Legal |
|---|---|---|---|---|
| 1 - Básico | Clickwrap (checkbox + IP + timestamp) | Baixa | Mínima | Assinatura eletrônica simples (Lei 14.063/2020, Art. 4º, I) |
| 2 - Intermediário | OTP via SMS ou email | Média | Baixa | Assinatura eletrônica simples/avançada (Lei 14.063/2020) |
| 3 - Elevado | Biometria facial com liveness detection | Alta | Média | Assinatura eletrônica avançada (Lei 14.063/2020, Art. 4º, II) |
| 4 - Máximo | Certificado digital ICP-Brasil A1 | Muito alta | Média-Alta | Assinatura eletrônica qualificada (Lei 14.063/2020, Art. 4º, III) |
A Lei 14.063/2020 estabelece três categorias de assinatura eletrônica — simples, avançada e qualificada — para as interações com o poder público, classificação que o mercado adotou como taxonomia geral. A escolha do método de autenticação do signatário determina diretamente em qual categoria a assinatura se enquadra — e, consequentemente, qual sua força probatória em caso de disputa judicial.
O princípio fundamental é: o nível de autenticação deve ser proporcional ao risco do documento. Exigir certificado ICP-Brasil para aceitar um termo de uso de software é overkill. Aceitar apenas clickwrap para um contrato de compra e venda de imóvel é insuficiente.
Clickwrap: Consentimento por Checkbox
Como funciona
O clickwrap é o método mais simples de autenticação de signatário. O usuário visualiza o documento, marca uma checkbox de aceite e confirma. A plataforma registra o IP do dispositivo, timestamp, user-agent e a ação realizada. Não há verificação ativa da identidade — a premissa é que a pessoa com acesso ao link ou à sessão autenticada é o signatário pretendido.
Quando usar
- Termos de uso e políticas de privacidade
- Contratos de adesão de baixo valor
- NDAs internos entre colaboradores já autenticados no sistema
- Aceite de cláusulas regulatórias em fluxos de onboarding
- Documentos onde o signatário já está autenticado na sua aplicação
Implementação via API
Na API da SignDocs, o clickwrap é selecionado através do perfil de policy aplicado à transação. Para um aceite isolado (apenas clique), use o perfil CLICK_ONLY, que resolve a policy em uma única etapa do tipo CLICK_ACCEPT:
A resposta (201) inclui o transactionId, o status inicial (CREATED), o hash do documento e o array steps gerado pelo policy engine — no caso do CLICK_ONLY, uma única etapa CLICK_ACCEPT com order: 0 e status: "PENDING".
A plataforma gera automaticamente o texto padronizado de aceite e captura as evidências contextuais (IP, user-agent, geolocalização) — não há parâmetros de configuração a passar no request. Quando o signatário conclui o step, o resultado é registrado em StepResult.click com os campos {accepted, textVersion}, e um webhook STEP.COMPLETED é disparado.
OTP (One-Time Password): Verificação via SMS e Email
Como funciona
O OTP adiciona uma camada de verificação ao exigir que o signatário insira um código numérico de uso único, enviado para seu telefone celular (SMS) ou endereço de email. Isso prova que o signatário tem acesso ao canal de comunicação associado à sua identidade — um fator de posse (something you have).
O fluxo típico via API envolve dois momentos:
- Configuração: ao criar a transação, você seleciona um perfil de policy que inclua OTP (
CLICK_PLUS_OTP,BIOMETRIC_PLUS_OTP) ou monta umcustomStepscomOTP_CHALLENGEeOTP_VERIFY, e indica o canal preferido no camposigner.otpChannel. - Verificação: quando o signatário chega ao step OTP (via fluxo hospedado ou integração própria), a API dispara automaticamente o envio do código para o
signer.emailousigner.phoneconforme ootpChannel. O signatário insere o código, a API valida e marca o step comoCOMPLETED.
Implementação via API
O perfil CLICK_PLUS_OTP resolve a policy em três steps: CLICK_ACCEPT, depois OTP_CHALLENGE (envio do código) e OTP_VERIFY (validação). Para OTP por email, altere otpChannel para "email" (o código é enviado para o valor em signer.email):
Se precisar de OTP sem a etapa de clickwrap, use policy.profile = "CUSTOM" com customSteps: ["OTP_CHALLENGE", "OTP_VERIFY"]. Na forma CUSTOM as etapas são executadas na ordem declarada.
Considerações de segurança
- SMS vs. Email: SMS oferece maior garantia porque está vinculado a um chip físico (SIM card), mas é vulnerável a SIM swap. Email é mais conveniente, porém depende da segurança da conta de email do signatário.
- Tamanho, expiração e retentativas do código: são parâmetros gerenciados pela plataforma — não precisam ser declarados no request. A API aplica rate limiting automático para proteger contra brute-force, e códigos expirados são invalidados e podem ser reemitidos reiniciando o step.
- Resultado: o step emite
StepResult.otp = {verified, channel}, que é incorporado ao Evidence Pack final.
O OTP é particularmente eficaz em cenários onde você já possui o telefone celular ou email do signatário validado no seu sistema — como em plataformas de crédito, bancos digitais e sistemas de RH.
Biometria Facial via API: Liveness Detection e Selfie Matching
Como funciona
A biometria facial é o método de autenticação que oferece a maior garantia de identidade sem depender de certificados digitais. O processo envolve duas etapas técnicas:
- Liveness detection (prova de vida): A API verifica que há uma pessoa real diante da câmera, e não uma foto, vídeo ou máscara. Isso é feito através de desafios como movimentação da cabeça, piscadas ou análise de profundidade 3D.
- Face matching (comparação facial): A selfie capturada é comparada com uma foto de referência — tipicamente extraída de um documento de identidade (RG, CNH) que o signatário também envia durante o fluxo.
O resultado é um score de similaridade (0 a 100), e a API aceita ou rejeita a verificação com base em um threshold configurável.
Fluxo via API
A biometria facial é selecionada via perfil de policy. Para biometria isolada use BIOMETRIC; para biometria combinada com OTP use BIOMETRIC_PLUS_OTP; para validar a selfie contra a foto do documento de identidade use BIOMETRIC_DOCUMENT_FALLBACK (liveness + DOCUMENT_PHOTO_MATCH) ou BIOMETRIC_SERPRO (que cruza com a base DATAVALID do SERPRO):
Perfis biométricos e quando usar
- BIOMETRIC: prova de vida + comparação facial (steps
BIOMETRIC_LIVENESSeBIOMETRIC_MATCH, contra a foto de referência do enrollment ou areferenceImageenviada). - BIOMETRIC_PLUS_OTP: liveness + comparação facial + OTP. Agrega um fator de posse (canal configurado em
otpChannel) além da biometria. - BIOMETRIC_DOCUMENT_FALLBACK: liveness +
DOCUMENT_PHOTO_MATCH— a comparação é feita contra a foto extraída de um documento de identidade (RG, CNH) que o signatário captura no fluxo, com validação biográfica (nome, CPF, data de nascimento). Ideal quando não há enrollment prévio. - BIOMETRIC_SERPRO / BIOMETRIC_SERPRO_AUTO_FALLBACK: cruzam a biometria diretamente com a base DATAVALID do SERPRO (step
SERPRO_IDENTITY_CHECK). ExigecpfebirthDateno objeto signer. A versãoAUTO_FALLBACKcai para fluxo alternativo quando a consulta SERPRO não está disponível.
Os thresholds de liveness confidence e face match similarity são gerenciados pela plataforma — não existem parâmetros de configuração no request. Os valores efetivamente aplicados, e o score retornado pelo provider, ficam registrados no StepResult e no Evidence Pack.
Resposta de verificação
A biometria facial via API é ideal para contratos de crédito, financiamentos, seguros e qualquer cenário onde a identidade do signatário precisa ser comprovada de forma inequívoca. Os campos relevantes do StepResult são liveness.confidence, match.similarity, e, quando aplicável, documentPhotoMatch (com validação biográfica) ou serproIdentity (com consulta à base DATAVALID) — todos incorporados ao Evidence Pack final assinado.
policy no mesmo endpoint POST /v1/transactions. Você define o nível de segurança trocando o profile (ou montando uma composição CUSTOM com customSteps), sem mudar a integração. Fale com nossa equipe para receber as credenciais do sandbox gratuito — o acesso à API é um plano sob medida.
Certificados ICP-Brasil A1 (Software): Assinatura Qualificada via API
O que são certificados A1
Certificados digitais ICP-Brasil do tipo A1 são certificados em formato de software, armazenados em arquivos .pfx ou .p12 protegidos por senha. Diferentemente dos certificados A3 (que residem em hardware tokens ou smartcards), os certificados A1 podem ser utilizados programaticamente — o que os torna a única opção viável para assinatura qualificada via API.
A assinatura com certificado A1 via API produz uma assinatura qualificada nos termos da Lei 14.063/2020, que goza de presunção de veracidade perante terceiros — o mais alto nível de força probatória entre as assinaturas eletrônicas brasileiras. Para entender as diferenças entre simples, avançada e qualificada, veja as definições no glossário de assinatura digital.
Fluxo de assinatura A1 via API
O ponto central do modelo da SignDocs: a chave privada do signatário nunca sai da infraestrutura dele. A assinatura qualificada é um protocolo em duas fases entre o titular do certificado e a API — o servidor nunca vê a chave privada nem o arquivo .pfx:
- Preparação (
POST /v1/transactions/{id}/signing/prepare): o signatário envia apenas o certificado folha (a parte pública). O servidor resolve a cadeia ICP-Brasil completa automaticamente, prepara o PDF com o espaço reservado de assinatura e devolve o hash SHA-256 a ser assinado. - Conclusão (
POST /v1/transactions/{id}/signing/complete): o hash é assinado localmente com a chave privada do titular (RSASSA-PKCS1-v1_5) e a assinatura bruta volta ao servidor, que monta o contêiner PKCS#7/CMS, o incorpora ao PDF (PAdES) e sela a trilha no Evidence Pack.p7m.
Ao criar a transação, basta declarar policy.profile = "DIGITAL_CERTIFICATE" — o policy engine resolve a policy em dois steps: CLICK_ACCEPT (aceite) seguido de DIGITAL_SIGN_A1 (assinatura qualificada). No fluxo hospedado, a própria página de assinatura conduz o protocolo com o certificado A1 do signatário; em integrações diretas, sua aplicação executa as duas fases. O PDF resultante fica vinculado ao certificado ICP-Brasil do signatário e é verificável no Validador do ITI e em leitores compatíveis com PAdES.
Criação da transação com assinatura A1
O bloco opcional digitalSignature permite declarar motivo, localidade e contato, que são incorporados ao objeto de assinatura PAdES dentro do PDF. Os parâmetros técnicos da assinatura — padrão (PAdES para PDF; CAdES .p7s para documentos não-PDF), resolução da cadeia de certificação ICP-Brasil e carimbo de hora do servidor — são aplicados automaticamente pela plataforma e não precisam ser declarados.
Resultado da assinatura A1
Quando o step DIGITAL_SIGN_A1 conclui, o StepResult.digitalSignature registra os metadados da assinatura gerada:
O PDF assinado pode ser verificado em qualquer leitor PDF compatível (Adobe Acrobat, Foxit) ou no Verificador SignDocs. O Evidence Pack .p7m é retornado ao final do fluxo pelo endpoint de evidência, sendo a prova jurídica selada da transação inteira — incluindo steps de OTP, biometria, clickwrap e geolocalização. Para saber mais sobre como funciona a assinatura digital com criptografia, consulte O que é uma Assinatura Digital e Como Funciona e Evidence Pack .p7m como prova jurídica.
Composição Multi-Step: Combinando Métodos em uma Única Assinatura
A verdadeira potência de uma API de autenticação multimétodo está na capacidade de compor múltiplos métodos em sequência para um mesmo signatário. Em vez de escolher entre OTP ou biometria, você pode exigir OTP e biometria e clickwrap — tudo no mesmo fluxo de assinatura.
Como funciona a composição
A composição acontece em dois níveis: (1) perfis predefinidos resolvem combinações comuns em steps padronizados; (2) o perfil CUSTOM aceita um array customSteps com a sequência exata de StepType que você precisa. Os steps são executados na ordem em que aparecem em customSteps, e cada um precisa ser concluído com sucesso antes do próximo.
Cenários de composição recomendados
| Cenário | Profile / customSteps | Nível de Assurance |
|---|---|---|
| Contrato de crédito / financiamento | CUSTOM: OTP_CHALLENGE, BIOMETRIC_LIVENESS, BIOMETRIC_MATCH, CLICK_ACCEPT |
Alto |
| Abertura de conta bancária digital | BIOMETRIC_PLUS_OTP ou BIOMETRIC_SERPRO |
Alto |
| Contrato societário / alteração contratual | DIGITAL_CERTIFICATE |
Muito alto |
| Proposta de seguro | CLICK_PLUS_OTP (com otpChannel: "email") |
Médio |
| Procuração digital | CUSTOM: OTP_CHALLENGE, BIOMETRIC_LIVENESS, BIOMETRIC_MATCH, DIGITAL_SIGN_A1 |
Muito alto |
A composição é especialmente importante para atender requisitos regulatórios setoriais. Instituições financeiras reguladas pelo Banco Central, por exemplo, frequentemente precisam comprovar que o signatário foi identificado por múltiplos fatores. Seguradoras reguladas pela SUSEP podem ter exigências similares para apólices de determinado valor. Para créditos e financiamentos envolvendo benefícios previdenciários, a NT65/2023 impõe SERPRO_IDENTITY_CHECK — use os perfis BIOMETRIC_SERPRO ou BIOMETRIC_SERPRO_AUTO_FALLBACK.
Para entender como esses steps se encaixam no fluxo transacional completo — da criação da transação até o webhook TRANSACTION.COMPLETED e o retorno do Evidence Pack .p7m — consulte Fluxo Transacional de uma API de Assinatura Digital.
Matriz de Decisão: Qual Método Usar e Quando
A tabela abaixo cruza tipos de documentos com perfis de policy recomendados, considerando risco, requisitos legais e impacto na experiência do usuário. Use-a como guia para escolher o valor de policy.profile (ou os customSteps, quando aplicável) por tipo de documento na sua integração.
| Tipo de Documento | Risco | Profile / customSteps Recomendado | Tipo de Assinatura | Exige ICP-Brasil? |
|---|---|---|---|---|
| Termos de uso / Política de privacidade | Baixo | CLICK_ONLY |
Simples | Não |
| NDA / Acordo de confidencialidade | Baixo-Médio | CLICK_PLUS_OTP (otpChannel: "email") |
Simples | Não |
| Contrato de prestação de serviços | Médio | CLICK_PLUS_OTP (otpChannel: "sms") |
Simples/Avançada | Não |
| Contrato de trabalho (CLT) | Médio | CLICK_PLUS_OTP (otpChannel: "sms") |
Avançada | Não |
| Contrato de locação | Médio | BIOMETRIC_PLUS_OTP |
Avançada | Não |
| Proposta de crédito / financiamento | Alto | CUSTOM: OTP_CHALLENGE, BIOMETRIC_LIVENESS, BIOMETRIC_MATCH, CLICK_ACCEPT |
Avançada | Recomendado |
| Crédito consignado sobre benefícios INSS | Alto | BIOMETRIC_SERPRO ou BIOMETRIC_SERPRO_AUTO_FALLBACK (NT65) |
Avançada | Recomendado |
| Contrato de compra e venda de imóvel | Alto | CUSTOM: BIOMETRIC_LIVENESS, BIOMETRIC_MATCH, DIGITAL_SIGN_A1 |
Qualificada | Sim |
| Alteração contratual societária | Alto | DIGITAL_CERTIFICATE |
Qualificada | Sim |
| Procuração pública / digital | Muito alto | CUSTOM: OTP_CHALLENGE, BIOMETRIC_LIVENESS, BIOMETRIC_MATCH, DIGITAL_SIGN_A1 |
Qualificada | Sim |
| Atos perante órgãos públicos (e-Gov) | Muito alto | DIGITAL_CERTIFICATE |
Qualificada | Obrigatório |
Critérios para a decisão
Ao definir a configuração de autenticação por tipo de documento, considere quatro fatores:
- Requisito legal: Alguns documentos exigem assinatura qualificada (ICP-Brasil) por força de lei ou regulamento setorial. Quando não há obrigatoriedade legal, assinatura simples ou avançada é suficiente.
- Valor econômico: Quanto maior o valor envolvido, maior o incentivo para contestação. Métodos com maior assurance reduzem o risco de repúdio.
- Perfil do signatário: Usuários finais (B2C) tendem a ter menor tolerância a fricção. Signatários corporativos (B2B) aceitam processos mais rigorosos quando o contexto justifica.
- Volume de assinaturas: Em operações de alto volume (centenas ou milhares de assinaturas por dia), cada passo adicional impacta a taxa de conversão. Equilibre segurança com eficiência operacional.
Assinatura Expressa: a Mesma Policy como Checkout Embarcável
Todos os perfis e composições que você viu até aqui são construídos sobre o endpoint POST /v1/transactions, que dá controle total sobre cada step (criar transação, fazer upload, listar etapas, iniciar, concluir, finalizar, verificar evidência — oito chamadas orquestradas pelo seu backend). A API da SignDocs também oferece um modo drop-in: a Assinatura Expressa, exposta em POST /v1/signing-sessions, que encapsula todo o fluxo em uma única chamada e devolve uma URL de checkout hospedada pela plataforma.
O modelo de autenticação é exatamente o mesmo — o objeto policy aceita os mesmos PolicyProfile e customSteps — então tudo que foi descrito neste artigo se aplica aos dois endpoints. A diferença está em quem orquestra as etapas: na API de Transações você constrói a própria UI e guia o signatário step-by-step; na Assinatura Expressa, a página hospedada conduz o fluxo e redireciona para sua returnUrl quando conclui.
Criar uma sessão expressa multi-fator
Você pode redirecionar o signatário para url diretamente ou abrir em popup com o SDK JavaScript, montando o link completo como url + "?cs=" + clientSecret. Ao término, a sessão conclui em SigningSessionStatus = "COMPLETED", a transação subjacente em TRANSACTION.COMPLETED e o evidenceId aparece em GET /v1/signing-sessions/{id}/status e o Evidence Pack .p7m é baixado via GET /v1/transactions/{transactionId}/evidence — com os webhooks SIGNING_SESSION.COMPLETED avisando na hora.
Quando escolher cada caminho
| Aspecto | API de Transações (/v1/transactions) |
Assinatura Expressa (/v1/signing-sessions) |
|---|---|---|
| Chamadas para completar o fluxo | ~8 (token, criar, upload, listar, iniciar, concluir, finalizar, verificar) | 1 (criar sessão) + polling ou webhook |
| Controle sobre cada step | Total — você orquestra step a step no seu backend | Delegado — a página hospedada conduz |
| Frontend | Você constrói a UI de cada etapa | Redirect ou popup para página SignDocs |
Personalização visual (appearance) |
N/A (você tem total controle da sua UI) | Cores (marca, fundo, texto, botão), logo, nome da empresa |
Internacionalização (locale) |
N/A | pt-BR, en, es |
| Ideal para | Integração profunda, fluxo altamente customizado, white-label | Integração rápida, checkout embarcável, time-to-live em dias |
A recomendação prática: comece pela Assinatura Expressa para validar o caso de uso e chegar em produção rapidamente; migre para a API de Transações quando precisar de UI totalmente própria ou de orquestração fina (por exemplo, inserir lógica de negócio entre o step BIOMETRIC_LIVENESS e o DIGITAL_SIGN_A1). Ambos os endpoints compartilham os mesmos webhooks (STEP.*, TRANSACTION.*) e produzem o mesmo Evidence Pack .p7m ao final.
Perguntas Frequentes (FAQ)
Posso combinar múltiplos métodos de autenticação em uma única assinatura?
Sim. A API da SignDocs usa um modelo de Policy com Steps: você escolhe um PolicyProfile predefinido (CLICK_ONLY, CLICK_PLUS_OTP, BIOMETRIC, BIOMETRIC_PLUS_OTP, DIGITAL_CERTIFICATE, BIOMETRIC_SERPRO) ou monta uma composição sob medida com policy.profile: "CUSTOM" e um array customSteps (CLICK_ACCEPT, OTP_CHALLENGE, OTP_VERIFY, BIOMETRIC_LIVENESS, BIOMETRIC_MATCH, DOCUMENT_PHOTO_MATCH, SERPRO_IDENTITY_CHECK, DIGITAL_SIGN_A1, PURPOSE_DISCLOSURE). As etapas são executadas na ordem em que aparecem em customSteps e todas precisam ser concluídas antes que o documento seja assinado.
Qual a diferença entre autenticação do signatário e autenticação da API (OAuth 2.0)?
São camadas distintas. A autenticação OAuth 2.0 (client_credentials) identifica sua aplicação perante a API da SignDocs e gera um access_token JWT Bearer para fazer chamadas ao endpoint /v1/transactions. Já a autenticação do signatário é composta pelos steps da policy (CLICK_ACCEPT, OTP_CHALLENGE, BIOMETRIC_LIVENESS, BIOMETRIC_MATCH, DIGITAL_SIGN_A1 etc.) e verifica a identidade da pessoa que está assinando o documento. Ambas são necessárias: OAuth 2.0 para acessar a API, e os steps da policy para validar quem assina.
A biometria facial coletada é armazenada pela SignDocs?
A SignDocs processa a imagem facial exclusivamente para fins de verificação de identidade durante o ato de assinatura. A imagem é comparada com o documento de identidade fornecido, e o resultado (match/no-match com score de confiança) é registrado na trilha de auditoria. O tratamento segue as diretrizes da LGPD, com base legal na execução contratual, e os dados biométricos são tratados como dados sensíveis conforme o Art. 11 — com prazos de guarda documentados na Tabela de Retenção pública da SignDocs.
Posso usar certificados A3 (token/smartcard) via API?
Não. A assinatura com certificados A3 (hardware token ou smartcard) requer interação direta do titular com o dispositivo físico, o que inviabiliza a operação via API remota. Na API, a assinatura qualificada usa o certificado A1 do próprio signatário em um protocolo de duas fases (prepare + complete) em que a chave privada nunca sai da infraestrutura do titular (profile DIGITAL_CERTIFICATE, step DIGITAL_SIGN_A1). Para cenários que exigem A3, o signatário deve usar o SignDocs Brasil desktop assinador (Windows/macOS/Linux), que fala PKCS#11 diretamente com o dispositivo — sem Java applets, plugins de navegador ou middleware de terceiros.
Qual método de autenticação é mais adequado para contratos de alto valor?
Para contratos de alto valor (acima de R$ 50.000 ou com implicações jurídicas relevantes), recomendamos a composição de múltiplos métodos: certificado digital ICP-Brasil A1 para assinatura qualificada com presunção legal, biometria facial com liveness detection para prova robusta de identidade, e OTP por SMS como fator adicional. Essa combinação gera uma trilha de auditoria com três camadas de evidência, reduzindo significativamente o risco de contestação.
O clickwrap sozinho tem validade jurídica no Brasil?
Sim, o clickwrap possui validade jurídica no Brasil para a maioria dos documentos, com base na Lei 14.063/2020 que regulamenta assinaturas eletrônicas simples. Entretanto, sua força probatória depende do contexto: para termos de uso e políticas de privacidade é amplamente aceito, mas para contratos de maior valor ou complexidade, recomenda-se complementar com métodos adicionais (OTP, biometria) para reforçar a evidência de consentimento e identificação.
Como a API lida com falha na verificação biométrica?
Quando o step biométrico falha (confidence de liveness ou similarity de face match abaixo do threshold gerenciado pela plataforma), a etapa assume StepStatus = "FAILED" e um webhook STEP.FAILED é disparado para sua aplicação, com o serializado do Step e o StepResult no campo data (incluindo liveness.confidence e match.similarity). As retentativas internas do fluxo hospedado de liveness são gerenciadas pela plataforma. Para cenários que exigem fallback automático em caso de falha, use os profiles BIOMETRIC_DOCUMENT_FALLBACK (cai para DOCUMENT_PHOTO_MATCH) ou BIOMETRIC_SERPRO_AUTO_FALLBACK (cai para SERPRO_IDENTITY_CHECK). Se todos os steps falharem, a transação conclui com status FAILED e dispara TRANSACTION.FAILED.
Autenticação multimétodo. Uma única API.
Clickwrap, OTP, biometria facial e certificados ICP-Brasil A1 — todos selecionáveis através do campo policy no endpoint POST /v1/transactions. O acesso à API é um plano sob medida, com sandbox de homologação gratuito para testar cada perfil antes de produção.