Assinatura digital: SaaS, open source ou construir do zero

Quando a decisão entre construir e contratar chega à mesa, quase sempre alguém propõe um terceiro caminho: "tem biblioteca open source para isso, a gente monta em cima". A proposta parece o equilíbrio sensato entre pagar por um serviço e escrever tudo do zero — e é aqui que vale um esclarecimento que muda a conversa: as bibliotecas de assinatura resolvem o formato do arquivo, e param aí. Elas são excelentes no que fazem, e o que fazem é a parte do problema que já estava resolvida. Este guia compara as três abordagens contra a lista real de requisitos, para que a escolha seja feita por encaixe e não por preferência arquitetural.

A lista contra a qual comparar

Comparar abordagens sem uma lista de requisitos produz discussão de preferência. Com a lista, a conversa fica curta. Estes são os componentes de um sistema de assinatura em produção:

1. Aplicar a assinatura criptográfica ao documento, no formato correto
2. Validar a cadeia de certificação e o estado de revogação no momento do ato
3. Verificar a identidade de quem assina — clique, código, biometria, certificado
4. Orquestrar múltiplos signatários, com ordem, prazos e concorrência
5. Compor e selar a evidência do ato
6. Permitir que um terceiro confira essa evidência sem depender de você
7. Entregar o documento e fazer a pessoa concluir
8. Reter e eliminar dados conforme política, com registro
9. Manter tudo disponível, monitorado e com plano de incidente

O que cada abordagem cobre

Duas colunas dessa tabela são quase idênticas, e é esse o ponto. A diferença entre "biblioteca" e "do zero" é uma linha e meia de nove — a mais fácil delas. Como decisão de implementação dentro da opção construir, usar uma biblioteca é obviamente certo; ninguém deveria escrever um assinador de PDF do nada. Como estratégia, ela não é uma terceira via.

Onde a linha 2 fica "parcial"

Vale detalhar, porque é o item que gera mais surpresa. Bibliotecas maduras oferecem primitivas para construir e validar cadeias de certificação, e algumas trazem suporte a consulta de revogação. O que elas não trazem é a política: quais âncoras de confiança aceitar, como tratar as particularidades da hierarquia brasileira, o que fazer quando o serviço de revogação não responde, e como registrar a decisão tomada para que ela seja auditável depois.

Essa política é código seu, e é o tipo de código que parece pronto até encontrar o certificado de um cliente específico que não se comporta como os que você testou.

Os custos que trocam de rubrica

"Open source é grátis" é verdade sobre a licença e enganosa sobre o sistema. O custo não desaparece — muda de linha orçamentária:

A última linha é a única em que a biblioteca ganha de forma inequívoca — e é exatamente por ela que a opção existe. Se o seu requisito é controle fino sobre como a assinatura é aplicada, nenhuma API vai lhe dar isso, e a decisão está tomada.

Quando cada uma é a escolha certa

A primeira linha descreve um caso real e frequente: empresas que já têm identidade verificada por um sistema próprio, fluxo dentro do produto e política de evidência definida — e que precisam apenas assinar o arquivo no fim. Para elas, a biblioteca é a resposta certa e uma API completa seria excesso.

O caminho de volta, e por que ele importa na decisão

Vale considerar a reversibilidade antes de escolher, porque ela é assimétrica.

De SaaS para construído é relativamente barato: você já operou o fluxo, conhece os requisitos reais e sabe quais casos de borda existem de fato — que é a parte difícil de descobrir. A construção parte de uma especificação real em vez de uma imaginada.

De construído para SaaS tem um detalhe que costuma escapar: os documentos assinados pelo sistema antigo continuam existindo, e continuam precisando ser verificáveis. Migrar o fluxo novo é simples; garantir que o acervo antigo permaneça conferível é o que dá trabalho, e isso não some quando o sistema que o produziu é desligado.

A assimetria sugere uma ordem: quando a decisão está apertada, começar por SaaS preserva mais opções do que começar construindo.

Um roteiro de meia hora

1. Marque as nove linhas com o que o seu caso realmente exige. Nem todo projeto precisa das nove.
2. Risque o que já está resolvido em outro sistema seu.
3. Conte o que sobrou. Se sobrou só a linha 1, você está procurando uma biblioteca. Se sobraram seis, a conversa nunca foi sobre bibliotecas.
4. Só então compare ferramentas — e compare pelas linhas que sobraram, não pelas que já estavam resolvidas.

O passo 3 encerra a maior parte das discussões, porque torna visível uma confusão comum: comparar uma biblioteca com uma plataforma é comparar coisas de escopos diferentes, e quem faz essa comparação está, sem perceber, decidindo construir.

O inventário do que construir realmente exige está em construir ou contratar. Os critérios para avaliar um fornecedor, no checklist de 20 perguntas. E o que uma API de assinatura eletrônica entrega das nove linhas está descrito na visão geral da API.

Perguntas Frequentes