Resumo

  • Publicado em agosto de 2026 como uma Best Current Practice do IETF, o RFC 10017 recomenda fortemente um Backend for Frontend para aplicações empresariais, sensíveis ou que tratam dados pessoais, pois os tokens OAuth permanecem fora do navegador.
  • O BFF reduz roubo pontual, extração persistente e obtenção de tokens novos. Porém, código malicioso que compartilha a origem da aplicação ainda pode enviar solicitações amparadas pelo cookie. Provar custódia não prova intenção.

Um incidente pode terminar sem token desaparecido

A abertura é um cenário analítico construído, não a descrição de um caso público. Ela força a separar duas linhas de investigação. Onde ficaram as credenciais? E o que o contexto autenticado conseguiu fazer? A primeira pergunta pode receber uma resposta tranquilizadora enquanto a segunda revela uma perda concreta.

O RFC 10017 começa pela fronteira de privilégio do navegador. JavaScript malicioso executado na origem da aplicação não ocupa um compartimento inferior. Ele pode observar dados da página, acessar armazenamento da origem, interagir com contextos de mesma origem e enviar solicitações aos backends. Se uma dependência comprometida já está dentro desse espaço, talvez seja desnecessário copiar qualquer segredo.

O documento organiza a ameaça OAuth em quatro situações: roubo único de tokens existentes, captura persistente conforme eles giram, aquisição de tokens frescos por um novo fluxo de autorização e encaminhamento de solicitações pelo navegador da vítima. A quarta é decisiva. Ela explica como uma operação indevida pode surgir enquanto todas as credenciais permanecem exatamente onde a arquitetura pretendia guardá-las.

Para o BFF, uma chamada produzida por código legítimo e outra induzida por código hostil podem apresentar origem, cookie e formato idênticos. O navegador anexa a sessão. Em seguida, o BFF escolhe e anexa o token apropriado. O invasor obtém o efeito sem observar nenhum dos dois valores.

Assim, a frase “não houve roubo de token” encerra apenas uma parte do exame. Ela sustenta que um valor portador não saiu da custódia e não ficou disponível para repetição fora do cliente. Não responde se a sessão iniciou uma chamada proibida, se o mapa do proxy estava amplo demais nem se o serviço de recursos aplicou a política correta à ação final.

O BFF reduz a portabilidade do ataque

Um Backend for Frontend é um cliente OAuth confidencial. Ele mantém tokens de acesso e renovação no servidor, representa a sessão do usuário por meio de cookie e encaminha pedidos aos recursos depois de acrescentar o token necessário. O código do navegador recebe uma interface de sessão, não o material da credencial.

Esse arranjo produz uma melhoria real. Não existe token de acesso no runtime para ser copiado; a rotação do token de renovação permanece fora do alcance do script; um novo código de autorização não pode ser trocado sem as credenciais confidenciais do componente. O RFC considera mitigados os três primeiros cenários e recomenda esse desenho para situações em que dados e operações têm consequência relevante.

O encaminhamento pelo navegador continua possível. HttpOnly impede que JavaScript leia o cookie, mas não impede que o navegador o inclua numa solicitação aceita. Código da mesma origem pode chamar o endpoint do BFF, que recupera a sessão, seleciona o token e encaminha o pedido. A cadeia funciona conforme projetada, embora a intenção tenha sido capturada.

O ganho do BFF é restringir o invasor ao repertório que a sessão, as rotas e a autorização do recurso permitem. Ele dificulta transformar o comprometimento do cliente numa credencial portátil, reutilizável a partir de outro ambiente e possivelmente persistente. Não converte toda unidade de código presente na origem em principal confiável.

Essa diferença permite avaliar a arquitetura sem absolutos. Dizer que o BFF falhou porque ainda existe sequestro do cliente ignora a redução de consequências. Dizer que o BFF prova autorização ignora a ameaça residual que o próprio RFC descreve. A pergunta correta é qual perda o mecanismo evita e qual decisão continua atribuída a outro controle.

O cookie não pode ser lido, mas pode ser exercido

O BCP exige Secure e HttpOnly nos cookies usados pelo BFF. Também recomenda SameSite=Strict, caminho /, nenhum atributo Domain e um prefixo limitado ao host, salvo razão específica do ambiente. Essas propriedades diminuem exposição em trânsito, leitura por script e distribuição indevida entre hosts.

Elas não estabelecem vontade do usuário. Uma interação autenticada por cookie precisa de defesa CSRF apropriada. SameSite pode contribuir, mas subdomínios diferentes podem pertencer ao mesmo site mesmo sendo origens distintas. O comprometimento de um irmão de domínio pode reabrir uma rota de falsificação que uma verificação superficial julgava fechada.

CORS exige evidência igualmente concreta. Solicitações classificadas como safelisted podem sair sem preflight; o navegador talvez bloqueie apenas a leitura da resposta, não a alteração produzida. Um cabeçalho personalizado pode obrigar a preflight, desde que cada endpoint sensível rejeite de fato a ausência do cabeçalho. “CORS habilitado” não é um resultado de teste.

Sessão e tokens também possuem relógios. O BFF não deveria manter uma aparência de sessão ativa depois que o token de renovação expirou ou foi invalidado. De modo inverso, revogar um token sem relacioná-lo às sessões deixa dúvidas sobre quais navegadores perderam capacidade e em qual momento.

Uma investigação útil correlaciona emissão, renovação, expiração, encerramento e revogação. O cookie protegido deve ser tratado como autoridade ainda operacional enquanto o BFF o aceitar, não como um segredo passivo apenas porque o script não consegue lê-lo.

O mapa de saída do proxy é uma política

Guardar tokens é apenas uma função do BFF. A outra é traduzir uma chamada de entrada autenticada por cookie em uma chamada de saída autorizada por bearer token. Destino, caminho e método formam uma superfície de decisão.

O RFC 10017 exige controle rigoroso dessa saída. Hosts precisam estar em lista permitida. Partes dinâmicas do caminho devem ser validadas. Métodos podem e devem ser limitados por endpoint. Se o BFF funciona como proxy aberto, o código hostil pode tentar enviar um token válido ao host errado ou alcançar uma operação que a interface nunca deveria expor.

Considere /bff/contas/{id}. A rota não é mero encanamento. Ela define se a sessão pode consultar, alterar, transferir ou encerrar, e quais identificadores são aceitáveis. O serviço de recursos ainda precisa conferir audiência, escopo, sujeito e regra de negócio. Um mapeamento correto não concede automaticamente permissão para o efeito final.

Também é preciso ligar resposta e resultado. O BFF pode registrar sucesso enquanto o serviço conclui a operação de forma assíncrona, rejeita uma etapa posterior ou aplica uma repetição. Muitos usuários podem compartilhar o mesmo endereço de saída, fazendo limites baseados em IP confundirem uma comunidade com um único cliente. Identificador da solicitação, sessão, decisão da rota, token usado, política do recurso e estado final precisam compor uma única linha de evidência.

A centralização cria ainda uma questão de privacidade. O BFF observa todas as solicitações e respostas encaminhadas. Hospedá-lo com um terceiro reduz a presença de tokens no navegador, mas entrega ao intermediário uma visão ampla das atividades. Custódia da credencial e minimização de dados devem ser decididas separadamente.

Cada arquitetura deixa uma evidência diferente

O BCP compara três desenhos. No BFF completo, os dois tipos de token ficam no servidor e o componente faz proxy das chamadas. No backend mediador, credenciais de cliente e token de renovação ficam protegidos, mas tokens de acesso retornam ao navegador para chamadas diretas. No cliente somente de navegador, o próprio runtime realiza o fluxo OAuth e mantém os tokens.

O mediador não oferece a mesma consequência do BFF. Ele dificulta roubar a capacidade de renovação e concluir um novo código, porém o token de acesso está novamente disponível ao ambiente comprometido. Roubo desse token e sequestro do cliente permanecem. O desenho deve ser nomeado pelo fluxo efetivo, não por sua proximidade verbal com um backend.

O cliente no navegador enfrenta os quatro cenários. Authorization Code com PKCE é obrigatório, e tokens de renovação precisam girar ou estar vinculados ao emissor, com vida máxima ou período de inatividade. Tais controles limitam interceptação e permanência, mas não isolam código que já executa no mesmo contexto legítimo.

DPoP oferece outra barreira de alcance definido. Uma chave não exportável pode tornar um token roubado pouco útil fora do dispositivo. Ainda assim, o código comprometido pode fazer o navegador enviar pedidos. Se conseguir iniciar um novo fluxo, poderá tentar associar os novos tokens a uma chave sob seu domínio. Toda afirmação sobre vinculação deve indicar qual contexto emitiu a prova.

Há ainda casos em que OAuth não é necessário entre frontend e API. Quando ambos fazem parte da mesma aplicação e do mesmo domínio de confiança, autenticação federada seguida por uma sessão própria pode representar melhor a relação. Introduzir OAuth sem uma parte de recurso independente adiciona complexidade, tokens e pontos de observação sem criar uma nova fronteira.

Limitar a alegação ao que foi observado

O mérito do RFC 10017 está em comparar consequências sem prometer um enclave no navegador. O BFF é uma defesa forte contra exposição e mobilidade de tokens. Não certifica todo código da origem, não confirma a intenção por trás de cada chamada e não substitui autorização no serviço de recursos.

O registro operacional deve preservar a procedência de código e dependências, a origem, emissão e expiração da sessão, atributos da cookie, horário, método, caminho e classe do corpo, resultado CSRF e CORS, regra de encaminhamento, audiência e escopo, decisão do recurso, resposta, efeito empresarial e responsável pela reversão. Esses fatos pertencem a componentes e relógios diferentes.

Essa separação combina um padrão compartilhado com escolha local. A prática comum fornece um piso, enquanto limites de endpoint, dependências aceitas, anomalias, reversibilidade e consequência ficam com quem opera e assume o risco. O código em execução e as chamadas observadas valem mais que um desenho arquitetônico.

A entidade que arca com fraude, privacidade e indisponibilidade deve manter autoridade final para admitir, observar, interromper e desfazer. Colocar segredos no servidor é uma escolha prudente. Impedir que a sessão exerça autoridade ampla demais é o controle complementar.

Fontes