Uma API que consulta informações públicas e uma API capaz de acessar dados financeiros ou iniciar uma transação não carregam o mesmo risco. Parece óbvio, mas essa diferença precisa aparecer também na arquitetura de segurança digital.
À medida que instituições financeiras conectam aplicativos, parceiros, fintechs, serviços de pagamento e diferentes ecossistemas por APIs, autenticar uma aplicação e emitir um token já não é suficiente para resolver a equação inteira. É preciso garantir que a solicitação não foi manipulada, que o token não possa simplesmente ser reutilizado por quem o interceptar e que cliente, autorização e recurso continuem vinculados durante toda a operação.
É justamente para cenários de maior criticidade que existe o FAPI.
FAPI é uma família de perfis de segurança baseados em OAuth. Neste conteúdo, o foco está no FAPI 1.0 Advanced, versão para a qual o authcube possui certificações da OpenID Foundation.
Para bancos e fintechs, porém, a relação continua especialmente direta. Afinal, quando uma API pode expor informações financeiras, conceder acesso a uma conta ou participar de uma operação de pagamento, segurança não pode depender de uma implementação “quase certa”.
FAPI não substitui o OAuth 2.0, ele aumenta a régua
OAuth 2.0 é um framework de autorização extremamente flexível. E essa flexibilidade é justamente parte de sua força: diferentes arquiteturas podem escolher fluxos, mecanismos e extensões adequados aos seus casos de uso.
No entanto, liberdade demais em ambientes de alto risco também significa mais espaço para decisões de implementação diferentes (algumas mais seguras que outras).
O FAPI Security Profile reduz esse espaço. Em vez de criar um protocolo completamente novo, ele define requisitos mais restritivos sobre solicitações de autorização, autenticação do cliente, respostas e uso de tokens, elevando o nível de segurança e interoperabilidade em relação a uma implementação OAuth mais aberta.
O que muda na prática com o FAPI?
Alguns dos principais requisitos mostram bem essa diferença.
| Na jornada de autorização | O que o FAPI reforça | Por que isso importa |
| Solicitação de autorização | Request Object assinado em JWT (JAR) | Protege os parâmetros contra adulteração |
| Envio da solicitação | PAR pode ser utilizado | Reduz a exposição da solicitação no front channel |
| Com PAR | Uso de PKCE com S256 | Vincula o código ao cliente que iniciou o fluxo |
| Autenticação do cliente | Uso de mTLS ou private_key_jwt | Fortalece a comprovação de quem é o cliente que está se comunicando com o Authorization Server |
| Resposta de autorização | JARM ou ID Token como assinatura destacada | Protege a integridade da resposta |
| Access Token | Sender-constrained via mTLS | Um token capturado não pode ser simplesmente reutilizado por outro cliente |
No FAPI 1.0 Advanced, o Request Object assinado é obrigatório, enquanto PAR é opcional. Se PAR for utilizado, aí sim PKCE com S256 é exigido. A segurança começa antes, na própria forma como a autorização é solicitada e estabelecida.
PAR: reduzindo a exposição da solicitação de autorização
No FAPI 1.0 Advanced, o Pushed Authorization Request (PAR) pode ser utilizado para enviar a solicitação diretamente ao Authorization Server por um canal autenticado, antes do redirecionamento pelo navegador.
Quando PAR é utilizado, o perfil exige PKCE com S256, adicionando uma proteção importante ao processo de troca do Authorization Code.
JARM: proteção criptográfica da resposta de autorização
No FAPI 1.0 Advanced, JARM é uma das abordagens disponíveis para proteger a resposta de autorização.
Com ele, os parâmetros da resposta são encapsulados em um JWT assinado, permitindo ao cliente verificar sua integridade e autenticidade antes de continuar o fluxo.
A outra abordagem prevista pelo perfil utiliza o OpenID Connect Hybrid Flow, com o ID Token funcionando como assinatura destacada da resposta.
PKCE: uma proteção adicional quando PAR entra no fluxo
No FAPI 1.0 Advanced, quando PAR é utilizado, o perfil exige PKCE com S256. A lógica pode ser resumida assim: quem iniciou a autorização precisa comprovar, durante a troca do Authorization Code, que é quem realmente começou aquele fluxo. Isso dificulta o aproveitamento de um código interceptado por outro cliente.
Um token roubado não pode virar um passe livre
O FAPI 1.0 Advanced utiliza Mutual TLS (mTLS) para vincular o access token ao cliente autorizado a utilizá-lo.
O objetivo é simples de entender: ter o token não basta. O cliente também precisa comprovar a posse da chave associada ao certificado ao qual aquele token foi vinculado.
Para APIs que movimentam informações e operações críticas, essa é uma diferença importante. Mesmo que um access token seja interceptado, ele não pode ser simplesmente reutilizado por outro cliente.
FAPI e Open Finance: cuidado com a confusão de nomes
FAPI-BR v2, utilizado no ecossistema brasileiro de Open Finance, não é sinônimo de FAPI 2.0 da OpenID Foundation. Os perfis brasileiros FAPI-BR v2 aparecem no programa de certificação da OIDF dentro da família FAPI 1.
A semelhança na nomenclatura pode confundir. Arquiteturalmente, são referências diferentes.
Então FAPI é só para bancos?
Não. O próprio FAPI Working Group define atualmente o perfil como um padrão de alta segurança de propósito geral para proteção de APIs. Open Banking e Open Data são alguns dos ecossistemas que impulsionaram sua adoção, mas os princípios podem ser relevantes sempre que uma API controla ativos, informações ou operações cujo comprometimento tenha impacto elevado.
Finanças são um caso particularmente evidente porque o risco é fácil de enxergar, mas APIs de saúde, seguros, identidade e outros ambientes críticos podem enfrentar desafios semelhantes.
Eu sou um bloco de texto. Clique no botão Editar (Lápis) para alterar o conteúdo deste elemento.
O desafio não é apenas “suportar FAPI”
Existe uma armadilha comum quando novos padrões chegam à arquitetura: transformar conformidade em checklist.
Suporta OAuth? Sim.
Protege a solicitação de autorização? Sim.
Tem mTLS? Sim.
Então está resolvido? Não necessariamente.
Os mecanismos precisam funcionar como uma arquitetura coerente de identidade e autorização. É preciso saber quem está solicitando acesso, validar o cliente, estabelecer corretamente a autorização, emitir tokens com as proteções adequadas, controlar seu uso nos Resource Servers e manter rastreabilidade sobre essas decisões.
E isso precisa conviver com APIs já existentes, sistemas legados, diferentes provedores e novas jornadas que continuam chegando.
Padrão aberto resolve interoperabilidade. Orquestração resolve como tudo isso funciona junto.
Onde o authcube entra nessa arquitetura
O authcube conecta autenticação, autorização, risco e orquestração em uma única plataforma low-code. Sua arquitetura foi construída para integrar sistemas, APIs e diferentes provedores sem exigir que cada nova jornada recrie toda a camada de identidade do zero.
A plataforma também possui certificações da OpenID Foundation para FAPI 1.0 Advanced, incluindo perfis de OpenID Provider com mTLS, private_key_jwt, PAR e JARM.
Essas certificações validam a conformidade da implementação com diferentes combinações previstas no FAPI 1.0 Advanced e reforçam a capacidade da plataforma de atuar em arquiteturas de APIs que exigem controles elevados de autenticação e autorização.
Isso importa porque a evolução para arquiteturas de maior segurança não acontece instalando “FAPI” como mais uma função. Ela depende de uma base consistente de identidade, autorização, protocolos abertos, gestão de tokens e integração.
É aí que o authcube atua: abstraindo a complexidade dessa camada para que padrões de segurança façam parte da arquitetura — e não virem mais um projeto isolado para o time manter.
APIs de alto valor pedem uma arquitetura à altura
APIs mudaram a forma como serviços financeiros são construídos, distribuídos e conectados. Quanto mais importante é aquilo que passa por elas, menos espaço existe para implementações ambíguas de segurança.
O FAPI 1.0 Advanced eleva essa régua ao proteger diferentes momentos da autorização: a solicitação, a autenticação do cliente, a resposta e o uso dos access tokens.
Request Objects assinados, autenticação forte de clientes, tokens vinculados via mTLS e mecanismos como JARM — além de PAR com PKCE quando adotado — ajudam a construir uma arquitetura mais resistente para operações de alto valor.
Para instituições que estão modernizando suas APIs, o próximo passo deveria ser tornar identidade e autorização uma base capaz de evoluir junto com os padrões, e não adicionar mais uma camada desconectada à arquitetura.
Se a sua empresa está revisando a segurança das APIs financeiras ou planejando a evolução da arquitetura de identidade, fale com nossos especialistas e entenda como o authcube pode simplificar essa jornada com padrões abertos, orquestração e segurança by design.
