Resumo

  • RFC 10017 apresenta, em ordem decrescente de segurança, o BFF completo, o backend mediador de tokens e o cliente OAuth executado no navegador.
  • O BFF mantém access token, refresh token e credenciais de cliente confidencial fora do JavaScript, mas código malicioso na origem aprovada ainda pode usar a sessão por cookie para enviar comandos ao próprio BFF.
  • A governança precisa cobrir origem e software executável, cookies e CSRF, destinos e métodos do proxy, audience e scope, autorização do recurso, confirmação de efeitos irreversíveis, revogação e prova do commit.

Um portal de tesouraria foi desenhado para que nenhum token OAuth entrasse no navegador. A sessão usa cookie HttpOnly; o BFF guarda as credenciais e chama o serviço de pagamentos. A equipe confirma, corretamente, que copiar o JavaScript não revela access token nem refresh token.

Uma dependência comprometida então envia uma ordem para trocar o favorecido de uma remessa. O navegador inclui o cookie. O BFF recupera o token do usuário e encaminha a chamada. O serviço aceita issuer, audience e scope. O segredo permaneceu no servidor; o dinheiro seguiu o comando indevido.

RFC 10017, publicado em agosto de 2026 como Best Current Practice do IETF, não diminui o valor do BFF. Ele mostra por que esse valor deve ser descrito com precisão. Tirar tokens do JavaScript impede certas formas de roubo e aquisição. Não transforma a origem do navegador em uma autoridade capaz de falar sempre pela pessoa.

Quatro capacidades depois da execução maliciosa

O RFC começa quando JavaScript ou WebAssembly hostil já roda no contexto da aplicação. Nesse ponto, o código recebe os privilégios que o navegador concede ao aplicativo: acesso a dados e storage disponíveis, interação com contextos de mesma origem, alteração do fluxo e emissão de requests a partir da origem aceita.

A primeira ameaça copia uma vez os tokens existentes. A segunda mantém um coletor e captura cada renovação. A terceira ignora o storage e abre um novo Authorization Code flow, aproveitando a sessão do usuário no Authorization Server para emitir outro conjunto. A quarta não extrai token: usa o navegador, o cookie ou o componente que acrescenta credenciais para enviar a chamada ali mesmo.

Essa divisão impede conclusões exageradas. Access token curto reduz o tempo de uma cópia, mas código persistente espera o próximo. Refresh token rotation pode detectar reutilização, mas o atacante pode roubar sempre a versão mais nova e impedir o uso legítimo. Isolar um token num Worker protege o objeto armazenado, não necessariamente o endpoint que emite outro.

PKCE protege o Authorization Code contra interceptação e injeção. Não separa a intenção de duas rotinas que já rodam no mesmo redirect origin. DPoP e chaves não exportáveis limitam o uso externo de uma cópia, mas o código hostil pode iniciar um novo flow com sua própria chave ou usar uma capacidade viva. Custódia de chave e intenção do programa continuam distintas.

O BFF transfere o cliente e concentra a decisão

No BFF completo, o componente de servidor é o cliente OAuth confidencial. Ele executa Authorization Code com PKCE, conserva os tokens, associa-os à sessão por cookie e faz proxy de todas as chamadas aos Resource Servers. O frontend não recebe token OAuth.

Três caminhos ficam fechados. Não há token no contexto do navegador para roubo pontual ou contínuo. Mesmo que obtenha um code, o script não possui as credenciais confidenciais do BFF para trocá-lo como aquele cliente. HttpOnly também impede que ele leia o identificador de sessão e leve a sessão para fora do navegador.

O quarto caminho é o próprio contrato funcional. A aplicação precisa mandar o BFF agir. Código hostil dentro da origem também pode chamar o endpoint. O browser acrescenta o cookie e o BFF traduz a sessão para um request com token. O atacante usa autoridade in-context sem nunca possuir a credencial.

Por isso, o BFF não pode ser um proxy aberto. RFC 10017 exige controle rigoroso das saídas: hosts e paths aprovados, além de métodos limitados por endpoint. Um parâmetro de URL não deve escolher livremente onde o access token será enviado. Um relay genérico aumenta o alcance de qualquer script que consiga operar a sessão.

Os cookies têm condições próprias. Secure e HttpOnly são obrigatórios; SameSite=Strict, path /, ausência de Domain e prefixo vinculado ao host são recomendações. Mesmo assim, rotas que alteram estado precisam de proteção CSRF, pois o navegador pode anexar o cookie sem expor seu valor ao JavaScript.

O BFF passa a concentrar segredo de cliente, vault, sessão e roteamento. Essa posição favorece detecção de anomalia e rate limiting. Também cria dependência de capacidade, coerência regional, revogação e recuperação que precisa ser assumida, não escondida sob o rótulo “backend”.

A mediação mantém o refresh token e devolve o access token

No backend mediador, o servidor continua como cliente confidencial e guarda o refresh token. Porém, entrega access tokens ao navegador, que chama os Resource Servers diretamente. O desenho reduz o custo de proxy, mas devolve ao frontend exatamente a autoridade de curto prazo que decidiu expor.

Código hostil não rouba o refresh token e não conclui sozinho um novo flow como cliente confidencial. Ainda pode copiar o access token. Se o token for isolado, pode solicitar a versão atual ao mediador usando a sessão. Uma janela curta pode bastar para um resultado irreversível.

DPoP também encontra uma divisão não definida: o backend obtém o token, enquanto o navegador o usa. RFC 10017 não padroniza essa repartição de prova. A arquitetura deve demonstrar quem possui a chave e produz cada proof, e não apenas marcar duas caixas como sender-constrained. O documento recomenda avaliar primeiro um BFF e recorrer à mediação quando requisitos concretos impedirem o proxy completo.

O cliente de navegador continua público

Quando o frontend assume todas as responsabilidades OAuth, um segredo empacotado no código não é confidencial. Authorization Code com PKCE, redirect URI exata e proteção CSRF são requisitos. Caso sejam emitidos refresh tokens, o Authorization Server deve rotacioná-los ou vinculá-los ao emissor, além de impor vida máxima ou expiração por inatividade.

Essas regras são necessárias, mas não anulam os quatro ataques depois que a origem é controlada. A própria origem — esquema, host e porta — vira unidade de poder. RFC 10017 recomenda uma aplicação por origem, tornando CORS, CSP e mensagens entre janelas compatíveis com um responsável identificável.

CORS decide se uma resposta cross-origin pode ser exposta ao código do navegador. Não é autorização no servidor e não separa script legítimo de script hostil dentro da origem permitida. Em postMessage, a aplicação deve verificar com exatidão a origem emissora e a receptora.

Um Service Worker não governa a origem

Um Service Worker consegue esconder tokens em memória isolada e inseri-los nos requests. À primeira vista, parece um BFF local. RFC 10017 não recomenda que ele controle o flow OAuth: código hostil pode cancelar seu registro e abrir um novo contexto sem a interceptação, no qual inicia outro flow.

O Worker protege a realidade do token existente, mas não adquire autoridade irremovível sobre a origem. O mesmo limite vale para chave Web Crypto não exportável. A API impede ler o material, sem prometer TPM ou filesystem cifrado, e o ambiente ainda pode usar a chave a pedido de código errado.

A trilha deve terminar no efeito

Uma evidência útil liga versão e origem do frontend, dependências e CSP, hash de sessão, resultado CSRF, rota do BFF, host/path/método de saída, audience e scopes, versão da política do recurso, estado do objeto, chave de idempotência e commit. Tokens, cookies e segredos brutos não precisam ser gravados.

Os testes negativos devem separar capacidades: ler token, acompanhar rotação, iniciar novo flow, pedir token ao mediador, ordenar pelo BFF sem ver token, manipular destino e repetir uma operação após resposta perdida. Um sinal único “OAuth válido” elimina a informação necessária para atribuir responsabilidade.

Running-Code Primacy exige que a autoridade venha dos controles em execução, não da palavra BFF. Minimum Initial Specification mantém os mecanismos comuns de OAuth verificáveis; autorização da consequência permanece no serviço que suporta a perda. Uma credencial bem protegida é uma realidade, não uma procuração para qualquer comando.