Chave própria no fornecedor (BYO-key): quando plugar a sua credencial compensa
Os três arranjos para consultar uma fonte externa paga: o fornecedor revende, você pluga a sua chave (BYO-key) ou integra direto. Comparação por preço, contrato, quota, LGPD e sublicenciamento.
Verificação de identidade quase nunca é autossuficiente. Em algum ponto alguém precisa perguntar a uma fonte externa paga se aquele documento existe ou se o quadro societário bate. Entre você e essa fonte há um contrato comercial e uma credencial de acesso, e a pergunta é de quem eles são.
Há três respostas possíveis, e só três: o fornecedor tem o contrato e revende a consulta, você tem o contrato e ele apenas orquestra a chamada, ou você integra direto e o fornecedor não entra nesse pedaço. O arranjo do meio aparece nas telas de configuração como BYO-key, do inglês bring your own key, traga a sua própria chave.
Este artigo compara os três, mostra o motivo contratual do BYO-key e desce na engenharia de guardar credencial alheia.
Os três arranjos, sem eufemismo
Na revenda, o fornecedor mantém o contrato, consome a quota dele e cobra um preço por consulta que embute custo mais margem. Você recebe uma fatura só.
No BYO-key, o contrato é seu: você cadastra a credencial da fonte no fornecedor e ele passa a chamar em seu nome. A fonte fatura o consumo; o fornecedor fatura a orquestração: decidir quando chamar, montar o pedido, interpretar a resposta, tratar erro e registrar evidência.
Na integração direta, o seu backend fala com a fonte sem intermediário: menos partes móveis, e a orquestração vira código seu.
Os critérios que separam os três
- Preço e captura de margem. Na revenda, a diferença entre o custo da fonte e o preço da consulta fica com o fornecedor. No BYO-key, fica com você, se o seu volume render preço de tabela melhor que o de balcão.
- Com quem é o contrato. Decide quem responde quando a fonte muda o termo de uso ou sobe o preço, e esse direito costuma ser amplo do lado da fonte. Os Termos de Uso das APIs da Microsoft, interface de programação de aplicações, declaram em letra maiúscula que ela pode alterar ou descontinuar as APIs a qualquer momento e modificar os próprios termos com ou sem aviso prévio. No BYO-key esse aviso chega a você; na revenda, você descobre pelo efeito.
- Limite de taxa e quota, e de quem é a fila. Quota costuma ser atributo da credencial, não do software que a usa. A documentação de limites da API REST do GitHub é explícita: as requisições contam contra o limite de quem autenticou, e o estouro devolve 403 ou 429. No BYO-key, um pico do seu funil consome a sua quota; na revenda, você a divide com os outros clientes do fornecedor sem enxergar a disputa.
- Quem enxerga a fatura. No BYO-key você lê o consumo no painel da fonte. Na revenda, a contagem do fornecedor é a única versão.
- Quem responde ao titular. A Lei 13.709/2018, a LGPD, define no artigo 5º o controlador como quem decide sobre o tratamento e o operador como quem trata em nome dele. Plugar a sua chave não muda os papéis: quem consulta continua controlador, o fornecedor que orquestra continua operador, e seguem valendo o artigo 39, que manda o operador tratar segundo a instrução do controlador, e o artigo 42, parágrafo 1º, inciso I, que responsabiliza solidariamente o operador que a ignora. Ter o contrato no seu nome muda a conta comercial, não a moldura descrita no contrato entre controlador e operador.
- O que acontece quando a fonte cai. A diferença é o poder de agir: no BYO-key você abre chamado com a fonte; na revenda, abre chamado com quem vai abrir chamado.
Sublicenciamento: o motivo real de existir o BYO-key
O motivo mais forte do BYO-key não é técnico: está no contrato da fonte. Há fontes que proíbem a revenda por escrito. Os Termos de Uso das APIs da Microsoft trazem, na lista do que o desenvolvedor não pode fazer, a vedação de redistribuir, revender ou sublicenciar o acesso às APIs e aos dados obtidos por meio delas. O mesmo documento diz que as credenciais de acesso são intransferíveis e que toda atividade feita com elas é responsabilidade de quem as recebeu. Somadas, elas desenham o BYO-key: se o dado não pode ser revendido e a credencial não pode ser repassada, resta ao cliente contratar a fonte no próprio nome e autorizar um software a usá-la.
Se o seu fornecedor revende consultas de uma fonte que veda revenda, o problema não fica contido nele. O mesmo documento da Microsoft reserva à empresa suspender ou encerrar o acesso a qualquer tempo, a seu critério exclusivo, e essa suspensão não avisa o cliente final do intermediário: o seu cadastro para de aprovar num dia útil qualquer. Perguntar "com que base contratual você me revende esta fonte" é pergunta de continuidade de negócio.
Guardar credencial de terceiro é engenharia, não campo de formulário
Aceitar a chave de outra pessoa cria um alvo. As regras:
Cifrada em cofre, nunca no navegador. O OWASP, Open Worldwide Application Security Project, recomenda no Secrets Management Cheat Sheet centralizar a gestão de segredos e aplicar privilégio mínimo, para que nem todo engenheiro alcance todos os segredos. E credencial de servidor não desce para o cliente: a documentação da Stripe diz que só as chaves publicáveis são seguras para expor fora do backend.
Nunca devolvida por leitura, e a razão aqui é outra. A credencial que você emite pode virar resumo criptográfico, porque conferir basta; a de terceiro, não, porque chamar a fonte em seu nome exige o valor original decifrado. Guardar de forma reversível é requisito, não descuido, e é por isso mesmo que a leitura não pode existir: uma rota que devolve o valor claro é caminho de saída pronto. A interface prova que a credencial existe sem mostrá-la: apelido, últimos caracteres, data de cadastro, último uso. A Stripe faz assim: a chave secreta de produção que você mesmo cria é exibida uma vez, e a documentação avisa que não dá para recuperá-la depois.
Rotação prevista desde o primeiro dia. O mesmo guia do OWASP trata rotação como rotina, para que credencial roubada valha pouco tempo. A diferença aqui é quem manda no calendário: a credencial é da fonte, que pode expirar ou revogar sem consultar ninguém. O produto precisa suportar troca iniciada de fora, com a mecânica descrita em rotação de chave e segredo de webhook.
Falha explícita, sempre. Credencial inválida, expirada ou sem quota precisa virar estado próprio e visível, com o código devolvido pela fonte. Se a chamada falha em silêncio e o fluxo segue, você guarda uma consulta que não aconteceu com aparência de consulta feita, o desfecho de não encontrado não é não existe.
Um contrapeso passa batido, e tem dois lados. Sem validação nenhuma, a credencial errada fica parada até a primeira chamada real e derruba o cadastro de um cliente de verdade, com erro que ninguém entende. Com validação automática a cada valor colado, o campo responde "válida" ou "inválida" para qualquer coisa e vira oráculo: quem abre uma conta testa credencial roubada em lote, de graça, gastando quota e log alheios. A saída fica no meio: validação como ação explícita do dono da conta, com limite de tentativas por janela e registro na trilha de auditoria.
A conta de custo muda de forma
A comparação honesta soma duas linhas. No BYO-key você paga a fonte pelo consumo e o fornecedor pela orquestração; na revenda paga um número só. Comparar o preço da revenda com o da fonte, ignorando a orquestração, produz economia de planilha: o trabalho não some.
Some o que o contrato próprio traz de rígido: franquia mínima, faturamento independente do volume, fidelidade. Um mínimo alto derruba a vantagem unitária de quem ainda não tem escala. Na UNIFOKAL, o cliente pode plugar a credencial dele em um fornecedor externo e pagar apenas a orquestração.
A decisão prática
Volume alto e contrato próprio favorecem o BYO-key: a margem da revenda deixa de sair do seu bolso, a quota é sua e a fatura da fonte é auditável. Começo de operação favorece a revenda, pela simplicidade de uma integração e uma fatura. Integração direta só compensa com fonte única, porque da segunda em diante você reconstrói em casa a orquestração que comprava pronta.
A escolha entra na planilha dos demais critérios de como avaliar um fornecedor de KYC e muda com o tempo: o arranjo certo no primeiro ano raramente é o certo no terceiro.
Fontes citadas
- Lei 13.709/2018, LGPD, artigos 5º, incisos VI e VII, 39 e 42, parágrafo 1º, inciso I: LexML e publicação no Senado Federal
- Microsoft, Terms of Use - Microsoft APIs, seções 2, 3, 6 e 10: learn.microsoft.com
- OWASP, Secrets Management Cheat Sheet: cheatsheetseries.owasp.org
- Stripe, documentação de chaves de API: docs.stripe.com/keys
- GitHub, Rate limits for the REST API: docs.github.com