Métodos de autenticação de usuários para APIs de crédito

Última atualização: 15 de julho de 2026

Principais lições deste artigo

• OAuth 2.0 com OIDC, FAPI 2.0, mTLS, DPoP e MFA com LoA3 formam a pilha mínima de autenticação exigida para APIs de crédito no Open Finance Brasil.

• Fluxos de autenticação devem cobrir toda a jornada de crédito, da originação à formalização e cobrança, com tokens de curta duração e mecanismos sender-constrained.

• Conformidade com FAPI-BR v2.2.0, certificados ICP-Brasil e LoA3 reduz riscos regulatórios, operacionais e jurídicos em operações de crédito.

• Empresas que evitam construir toda a pilha internamente conseguem acelerar lançamentos e reduzir custos ao adotar infraestrutura já homologada.

• Acelerar o lançamento de produtos de crédito é possível com a infraestrutura de crédito completa da Celcoin.

Definição do tema e conceitos fundamentais

Os principais padrões de autenticação para APIs de crédito no Brasil formam uma pilha técnica interdependente que sustenta segurança e conformidade.

• OAuth 2.0 + OIDC: protocolo de autorização e camada de identidade que emite tokens de acesso com escopos granulares. No Open Finance, o Banco Central e os bancos participantes exigem OAuth 2.0 com OpenID Connect como fluxo padrão de autorização.

• FAPI 2.0 (Financial-grade API): perfil de segurança construído sobre OAuth 2.0 e OIDC que adiciona requisitos financeiros como tokens vinculados ao canal, pares de chaves assimétricas e verificação de integridade de requisições. O perfil FAPI é adotado para autenticação e autorização no Open Finance Brasil.

• mTLS (Mutual TLS): autenticação mútua via certificados digitais ICP-Brasil BRCAC, que garante autenticação de cliente e servidor. O Open Finance Brasil exige mTLS com certificados ICP-Brasil.

• DPoP (Demonstrating Proof of Possession, RFC 9449): mecanismo alternativo ao mTLS para vincular tokens ao cliente emissor, tornando o token inválido se outra máquina o reproduzir. O perfil FAPI 2.0 aceita DPoP e mTLS como mecanismos para tokens sender-constrained.

• MFA e LoA3: autenticação multifator exige ao menos dois fatores distintos, como conhecimento (senha), posse (token ou dispositivo) ou inerência (biometria). O uso de fatores repetidos deve ser evitado em implementações de MFA.

• JWT de curta duração: tokens de acesso com validade limitada, assinados e criptografados com algoritmos robustos, que reduzem a janela de exposição em caso de vazamento.

• PAR (Pushed Authorization Requests): requisições de autorização enviadas diretamente ao servidor antes do redirecionamento do usuário, o que reduz a superfície de ataque em parâmetros sensíveis.

• CCB (Cédula de Crédito Bancária): instrumento jurídico de formalização de operações de crédito, cuja emissão digital exige autenticação LoA3 e mTLS para garantir validade jurídica.

Como o tema funciona na prática?

A jornada de crédito via APIs reguladas percorre etapas com requisitos de autenticação distintos e complementares.

• Originação (score e simulação): o originador autentica-se via mTLS com certificado BRCAC e solicita escopos de leitura como LOANS_READ e FINANCINGS_READ. Para APIs de leitura, o nível LoA2 é comumente aplicado. O token de acesso, com validade limitada, é vinculado ao consentimento específico.

• Aprovação e formalização (emissão de CCB): operações de escrita exigem LoA3. Para APIs de contratação de produtos e serviços de crédito, recomenda-se autenticação compatível com LoA3. O fluxo CIBA (Client-Initiated Backchannel Authentication) permite aprovação desacoplada: o cliente autentica-se via mTLS com certificados BRCAC e private_key_jwt no endpoint de autenticação backchannel.

• Cobrança e gestão de carteira: tokens sender-constrained via DPoP ou mTLS garantem que operações de cobrança não possam ser reproduzidas por terceiros. Webhooks precisam de proteção contra replay com validação de jti único por clientId em janela de 24 horas.

Tokens emitidos para compartilhamento de dados de transação são somente leitura e não podem ser usados para solicitar empréstimos, emitir CCBs ou realizar operações de escrita. A separação de escopos por operação funciona como controle de segurança estrutural.

Panorama do mercado e ecossistema

A Resolução Conjunta nº 16/2025, com prazo de adequação até 31 de dezembro de 2026, estabelece responsabilidade compartilhada em operações BaaS e exige KYC reforçado pela instituição autorizada, o que impacta diretamente a autenticação em APIs de crédito e exige trilhas de auditoria completas. Esse requisito de auditoria se conecta diretamente à Instrução Normativa BCB nº 725, que disciplina testes de produção de compartilhamento de dados no Open Finance e exige conformidade contínua das APIs para fluxos de dados de crédito. Juntas, essas normas elevam a complexidade técnica e o custo de construção interna de uma pilha FAPI 2.0 completa, incluindo gestão de certificados ICP-Brasil, rotação de chaves, conformidade com cipher suites obrigatórias e testes de homologação, o que torna a escolha de infraestrutura um fator estratégico para empresas de todos os portes.

Critérios de análise e boas práticas

Alguns critérios formam uma base de prioridades técnicas e regulatórias para implementar autenticação segura em APIs de crédito.

• Integração: solicitar apenas os escopos OAuth mínimos necessários reduz superfície de ataque e facilita homologação. Essa granularidade de escopos serve de base para os demais controles.

• Escalabilidade: depois de definir escopos e fluxos, implementar mTLS com emissão centralizada via PKI e rotação automática de certificados garante suporte a alto volume sem comprometer segurança.

• Compliance: com a infraestrutura de autenticação em operação, monitorar renovações de consentimento torna-se crítico, pois anteriormente os consentimentos no Open Finance Brasil eram limitados a 12 meses, mas desde 2024 podem durar por tempo indeterminado, e a interrupção do fluxo de dados impacta operações de crédito.

• Governança: manter máquina de estados de consentimento com transições explícitas, como AWAITING_AUTHORISATION, AUTHORISED e REJECTED, e rejeição automática após 60 minutos sem aprovação, melhora rastreabilidade e previsibilidade.

• Risco: validar campos de titularidade de conta, como CPF ou CNPJ retornados pelo endpoint /accounts, antes de prosseguir com a concessão de crédito reduz risco de fraude e erros cadastrais.

Erros comuns e pontos de atenção

• Usar LoA2 em fluxos de contratação de crédito quando LoA3 é exigido, o que expõe a instituição a risco regulatório.

• Não implementar PAR e deixar parâmetros de autorização expostos na URL de redirecionamento.

• Emitir tokens de longa duração em vez de adotar tokens com validade limitada.

• Reutilizar o mesmo fator de autenticação duas vezes, como duas senhas, e classificar isso como MFA, prática que deve ser evitada.

• Não validar o parâmetro state no retorno do banco, o que abre vetor para ataques CSRF.

• Ignorar a exigência de desabilitar TLS Session Resumption e TLS Renegotiation nos endpoints de autorização e recursos.

Comparações, aplicações e variações por perfil

A tabela abaixo mapeia os principais métodos de autenticação aos fluxos de crédito e perfis de empresa, e mostra a progressão de operações de leitura com LoA2 para operações de escrita com LoA3.

Método	Fluxo de crédito	Nível exigido	Perfil de empresa
OAuth 2.0 + OIDC + PKCE	Score, simulação, leitura de dados	LoA2	Fintechs, ERPs, varejistas
mTLS + private_key_jwt + PAR	Aprovação, emissão de CCB, cessão	LoA3	Originadores, correspondentes bancários
DPoP (RFC 9449) + JWT curta duração	Formalização, cobrança, gestão de carteira	LoA3	Gestoras de fundos, fintechs de crédito
CIBA + mTLS + MFA biométrico	Consentimento desacoplado, contratação	LoA3	Varejistas, correspondentes, originadores

Fintechs em estágio inicial tendem a iniciar com OAuth 2.0 e PKCE para leitura de dados e evoluir para mTLS e DPoP à medida que adicionam produtos de crédito com escrita. Varejistas e ERPs com alto volume de transações mensais precisam de infraestrutura com gestão automatizada de certificados ICP-Brasil. Gestoras de fundos exigem rastreabilidade completa de consentimentos e segregação de escopos por operação de carteira.

Infraestrutura completa para autenticação segura em APIs de crédito

A Celcoin não oferece empréstimo para consumidores finais. A Celcoin fornece infraestrutura tecnológica para que empresas consigam ofertar produtos de crédito aos seus clientes.

Para empresas que precisam operar com conformidade FAPI 2.0, mTLS, LoA3 e ICP-Brasil sem construir toda a pilha internamente, a infraestrutura de crédito completa da Celcoin cobre toda a jornada, da originação à cobrança, com licenças regulatórias próprias, como IP e SCD, APIs modulares e conformidade contínua com as normas do Banco Central. A solução abrange originação, formalização com emissão digital de CCB, gestão de carteira e integração neutra com gestoras de fundos.

Funcionalidade da Celcoin	Benefício para sua empresa
APIs modulares	Integrações mais rápidas, com redução de custos e prazos de desenvolvimento.
Experiência e suporte ao desenvolvedor	Documentação, SDKs e sandboxes reduzem ciclos de integração e custos de engenharia.
Capacidade de lançamento rápido	Módulos pré-construídos e entrega via SaaS aceleram lançamentos e melhoram o tempo para geração de receita.
Distribuição white-label e embutida	Suporte a produtos financeiros com marca própria em diferentes canais.
Escalabilidade com confiabilidade	Solução com alta disponibilidade e escalável na nuvem mantém serviços estáveis mesmo em altos volumes e protege a receita.
Cobertura de diversas possibilidades de pagamentos, incluindo crédito	Oferta de pagamentos e emissão de crédito aumenta conversão, ARPU e fidelização.
Acesso a dados e personalização	Dados e análises via Open Finance permitem ofertas personalizadas e melhoram conversão e retenção.
Compliance e conformidade como princípio	KYC, AML e relatórios integrados reduzem risco regulatório e aceleram ciclos de vendas.
Prevenção de fraude e controles de risco	Monitoramento baseado em IA e autenticação robusta reduzem estornos, perdas e exposição regulatória.
Força do ecossistema de parceiros da Celcoin	Parcerias e integrações com bancos, redes e fintechs ampliam cobertura, recursos e velocidade de entrada no mercado.

Conhecer a solução completa da Celcoin para APIs de crédito ajuda sua empresa a reduzir complexidade técnica e acelerar o go-to-market.

Perguntas frequentes

O que é FAPI 2.0 e por que ele é obrigatório para APIs de crédito no Brasil?

FAPI 2.0, ou Financial-grade API Security Profile, é um conjunto de requisitos de segurança construído sobre OAuth 2.0 e OpenID Connect e adotado pelo Open Finance Brasil como padrão obrigatório para APIs financeiras. Esse perfil adiciona controles como tokens sender-constrained, vinculados ao cliente via mTLS ou DPoP, Pushed Authorization Requests, assinatura de requisições com JWT e criptografia de respostas de autorização, conhecida como JARM. Para APIs de crédito, o FAPI 2.0 é mandatório porque operações de contratação, emissão de CCB e cobrança são classificadas como read-write e exigem nível de autenticação LoA3, que precisa ser atestado dentro de um fluxo compatível com FAPI. A Instrução Normativa BCB nº 720/2026 reforça essa exigência ao determinar o uso de certificados ICP-Brasil e algoritmos criptográficos avançados em toda a comunicação entre sistemas participantes do Open Finance.

Qual a diferença entre mTLS e DPoP para vinculação de tokens em APIs de crédito?

mTLS e DPoP são mecanismos para implementar tokens sender-constrained, ou seja, tokens que só são válidos quando usados pelo cliente que os solicitou. O mTLS vincula o token ao certificado digital do cliente, que no contexto brasileiro é um certificado BRCAC emitido por autoridade certificadora da ICP-Brasil. O DPoP, definido na RFC 9449, vincula o token a um par de chaves assimétricas gerado pelo cliente, sem depender de infraestrutura de certificados. Na prática, o mTLS é mais comum em integrações B2B entre instituições financeiras participantes do Open Finance, enquanto o DPoP oferece flexibilidade adicional em cenários com gestão de certificados mais complexa. O perfil FAPI-BR v2.2.0 aceita ambos como mecanismos válidos, e a escolha depende da arquitetura de cada operação de crédito.

Como o LoA3 se aplica especificamente à emissão de CCB e formalização de crédito?

Como explicado anteriormente, o LoA3 exige dois fatores distintos de autenticação, combinando elementos de conhecimento, posse ou inerência. No contexto de emissão de CCB e formalização de crédito, esse nível é mandatório porque essas operações são classificadas como contratação de produto ou serviço financeiro e se enquadram nas APIs de escrita do Open Finance Brasil. O Art. 17 da Resolução Conjunta nº 01 determina que instituições adotem método de autenticação compatível com LoA3 ou superior para esse tipo de operação. Na prática, o usuário final precisa passar por autenticação biométrica ou token físico combinado com senha antes que o sistema possa emitir o instrumento de crédito. Fluxos CIBA são frequentemente utilizados para desacoplar essa autenticação do canal principal e permitir aprovação via aplicativo do banco enquanto a operação aguarda no backchannel.

Quais são os principais riscos de não conformidade com o FAPI-BR para empresas que operam APIs de crédito?

A não conformidade com o FAPI-BR expõe empresas a riscos regulatórios, operacionais e jurídicos. No aspecto regulatório, a Instrução Normativa BCB nº 720/2026 e a Resolução Conjunta nº 16/2025 estabelecem obrigações com prazos definidos, e o descumprimento pode resultar em sanções do Banco Central e impedimento de participação no ecossistema Open Finance. No aspecto operacional, a ausência de mTLS, PAR ou tokens de curta duração aumenta a superfície de ataque e o risco de fraude em operações de crédito, com impacto direto em inadimplência e estornos. No aspecto jurídico, CCBs emitidas sem fluxo de autenticação adequado podem ter validade questionada, o que compromete a segurança jurídica da carteira de crédito. Empresas que utilizam infraestrutura já homologada pelo Banco Central reduzem esses riscos ao herdar a conformidade do provedor.

Como gestoras de fundos e originadores devem estruturar escopos OAuth para operações de crédito no Open Finance?

O Open Finance Brasil define agrupamentos mínimos de permissões para operações de crédito que precisam ser solicitados em conjunto. Para empréstimos e financiamentos, o conjunto inclui permissões de leitura de contratos, garantias, parcelas e pagamentos para as modalidades de loans, financings, invoice-financings e unarranged-accounts-overdraft. A seleção ocorre por agrupamento de produto, não por identificador individual de recurso, o que significa que o transmissor mantém todas as permissões solicitadas para o agrupamento mesmo que não ofereça atualmente aquele produto específico. Gestoras de fundos devem estruturar consentimentos com escopos segregados por operação de carteira e monitorar o ciclo de vida do consentimento, que passa pelos estados AWAITING_AUTHORISATION, AUTHORISED e REJECTED, para garantir que a expiração automática após 60 minutos sem aprovação não interrompa fluxos críticos de originação ou cessão de crédito.

Conclusão

A autenticação segura em APIs de crédito no Brasil representa um conjunto de requisitos regulatórios definidos pelo Banco Central e operacionalizados pelo perfil FAPI-BR v2.2.0. OAuth 2.0 com OIDC, mTLS com certificados ICP-Brasil, DPoP, MFA com LoA3 e tokens de curta duração formam a pilha mínima para operar com segurança jurídica e conformidade em toda a jornada de crédito, da originação à cobrança. Empresas que precisam lançar ou escalar operações de crédito sem construir essa infraestrutura internamente podem contar com parceiros que possuem licenças regulatórias próprias e APIs já homologadas para reduzir custo e tempo de implantação. Transforme seu negócio com a infraestrutura de crédito completa da Celcoin.