Quando lidamos com OAuth em uma Aplicação de Página Única (SPA), onde armazenar os tokens de acesso e atualização tem sido um debate de longa data. localStorage, sessionStorage e variáveis em memória são todos insuficientes contra XSS. O padrão Backend for Frontend (BFF) é um design onde os tokens são mantidos no lado do servidor, em vez de serem passados para o navegador. Este artigo organiza o mecanismo e os principais pontos de implementação.
Pré-requisitos
Este artigo assume o seguinte ambiente:
- Desenvolvimento de um aplicativo baseado em navegador usando OAuth 2.0 e OpenID Connect.
- Existência de uma SPA, as APIs que ela chama e um servidor de autorização.
- A SPA e seus componentes de servidor de suporte podem ser colocados no mesmo domínio pai.
- HTTPS é um pré-requisito (necessário para emitir Cookies Seguros).
Riscos de XSS em Aplicativos Baseados em Navegador
O código do aplicativo executado no navegador é vulnerável a tudo o que acontece no ambiente de execução do navegador. O XSS tem um grande impacto e, como o código de ataque é executado no mesmo contexto do aplicativo, as seguintes operações são possíveis:
- Ler valores armazenados em localStorage ou sessionStorage.
- Ler variáveis em memória acessíveis a partir do JavaScript.
- Executar todas as chamadas de API que o aplicativo pode realizar.
- Alterar o comportamento sobrescrevendo funções internas (poluição de protótipo).
Existem vários pontos de entrada para XSS, como vulnerabilidades em bibliotecas dependentes, falhas no processamento de entrada/saída do seu próprio código ou comprometimento de scripts de terceiros. Como é difícil prevenir completamente o XSS, uma política realista é "limitar o impacto se ocorrer uma intrusão."
Enquanto os tokens estiverem no navegador, a possibilidade de roubo de tokens por meio de XSS permanece. Se um invasor usar um token de atualização roubado em seu próprio ambiente, ele poderá chamar APIs por um longo tempo, mesmo depois que o usuário fechar o site. Embora a rotação de tokens e os tempos limite de inatividade possam mitigar o impacto, eles não são soluções fundamentais.
Design Que Não Coloca Tokens no Navegador
O padrão BFF fornece um componente de servidor dedicado à SPA e centraliza as responsabilidades do cliente OAuth nele. A SPA não lida diretamente com o processamento OAuth, mas realiza autenticação e chamadas de API por meio do BFF.
A divisão de papéis é a seguinte:
- Comunicação do protocolo OAuth com o servidor de autorização: Manipulada pelo BFF.
- Manter tokens de acesso e atualização: Apenas BFF.
- Manter o estado de autenticação entre SPA e BFF: Cookie HttpOnly.
- Chamadas de API: A SPA envia requisições para o BFF, e o BFF converte o Cookie em um token e o encaminha para a API.
Nesta configuração, os tokens circulam apenas entre o BFF e as APIs que ele chama, e são invisíveis para o JavaScript do navegador. Mesmo que ocorra XSS, um invasor não pode extrair o token e usá-lo de outro lugar. Tudo o que um invasor pode fazer é enviar requisições para o BFF dentro do escopo da sessão atualmente aberta pelo usuário. Embora esse impacto não seja desprezível, a duração e o escopo do impacto são significativamente limitados em comparação com o roubo de token.
O BFF atua como o que a terminologia OAuth chama de "cliente confidencial". Ele mantém um segredo de cliente e completa a troca de códigos de autorização por tokens e o processamento de atualização inteiramente no lado do servidor.
Fluxo de Autenticação
Um fluxo de autenticação típico é o seguinte:
- Quando a SPA inicia um login, ela envia uma requisição de login para o BFF.
- O BFF inicia um fluxo de código de autorização com PKCE, gera uma URL de redirecionamento para o servidor de autorização e a retorna para a SPA.
- A SPA transita o navegador para essa URL, e o usuário se autentica no servidor de autorização.
- O servidor de autorização retorna um código de autorização para a URI de redirecionamento do BFF.
- O BFF troca o código de autorização por tokens e obtém um token de acesso e um token de atualização.
- O BFF armazena os tokens em sua própria área segura (cookie criptografado, armazenamento de sessão do servidor, etc.) e retorna apenas um identificador de sessão para a SPA por meio de um Cookie HttpOnly.
- Quando a SPA chama uma API, ela envia a requisição por meio do BFF. O Cookie é enviado simultaneamente, e o BFF o converte em um token de acesso e o encaminha para a API upstream.
- Se o token de acesso expirar, o BFF o atualiza silenciosamente usando o token de atualização.
Da perspectiva da SPA, o estado de login é mantido pelo Cookie, e as requisições de API são concluídas com chamadas fetch normais. O código que lida diretamente com tokens OAuth ou códigos de autorização não existe na SPA.
Configurações de Segurança Necessárias
Os seguintes atributos devem ser definidos para o Cookie emitido pelo BFF:
- HttpOnly: Proíbe o acesso a partir do JavaScript. Mesmo com XSS, o conteúdo do Cookie não pode ser lido.
- Secure: Enviado apenas por HTTPS.
- SameSite=Strict: Garante que o Cookie não seja enviado com requisições de outros sites. Isso ajuda a bloquear os principais caminhos de ataque CSRF, mas a proteção CSRF não é concluída apenas com isso.
- Prefixo __Host-: Adicionar o prefixo __Host- ao nome do Cookie garante que o navegador limite o Cookie ao host emissor e não o compartilhe com subdomínios.
Se armazenar tokens em um Cookie criptografado (sessão do lado do cliente), o conteúdo do Cookie é criptografado. Se colocar tokens em um armazenamento de sessão do servidor (sessão do lado do servidor), o Cookie contém apenas um identificador de sessão, portanto, a criptografia não é necessária.
A Proteção CSRF Não Deve Confiar Apenas no SameSite
Como usa autenticação baseada em Cookie, o BFF deve implementar proteção contra CSRF. SameSite=Strict é uma etapa válida, mas não a solução completa. Cuidado especial é necessário em configurações onde a SPA está em www.example.com e o BFF em api.example.com. Como a determinação do SameSite é feita por site, e não por origem, requisições de outros subdomínios sob example.com são consideradas "mesmo site", e os Cookies serão enviados mesmo com SameSite=Strict.
Portanto, reforce a defesa CSRF com uma das seguintes opções:
- Se o BFF e a SPA estiverem em origens diferentes, use CORS e validação de cabeçalho Origin para defesa.
- Para requisições que alteram o estado, verifique os tokens CSRF usando o método anti-falsificação / double-submit cookie.
Limite CORS a Origens Exatas
O CORS deve ser permitido apenas para a origem exata da SPA. Para requisições autenticadas envolvendo Cookies, os navegadores não permitem curingas (*) em Access-Control-Allow-Origin. Portanto, o BFF deve refletir a origem exata da SPA na resposta. Essa limitação estrita das origens permitidas funciona como parte da defesa CSRF.
O gerenciamento de chaves é necessário para os dados de sessão mantidos pelo BFF, especialmente as informações de token armazenadas em Cookies criptografados. Incorpore operações para injetar chaves com segurança como configurações do BFF e girá-las regularmente.
Observe que colocar a SPA e o BFF no mesmo domínio pai é para satisfazer a condição de que os Cookies Same-Site funcionem como Cookies primários.
Evolução: BFF Orientado por API
Se um BFF for construído como um aplicativo web tradicional, a renderização do lado do servidor do BFF se envolve nas transições de página da SPA. Um BFF orientado por API minimiza esse impacto.
Os papéis são divididos em dois:
- Agente OAuth: Uma API responsável pelo processamento do protocolo OAuth. Ela é chamada pela SPA por meio de JSON.
- Proxy OAuth: Opera como um plugin de gateway de API, extrai o token do Cookie e o encaminha para a API upstream.
Nesta configuração, a SPA simplesmente chama o Agente OAuth como uma API REST normal. A experiência de desenvolvimento frontend da SPA pode ser mantida quase a mesma de antes da introdução do BFF.
Considerações para Adoção
Ao adotar o padrão BFF, considere o seguinte:
- Componentes arquiteturais adicionais aumentam os custos de desenvolvimento e operação.
- A SPA e o BFF devem ser colocados no mesmo domínio pai.
- Uma configuração que simplesmente encaminha o cabeçalho Authorization por meio de um proxy reverso não é um BFF. A essência de um BFF é manter o token como um cliente confidencial.
- PKCE e BFF são usados juntos, não como alternativas.
- O BFF deve verificar o host de destino antes de encaminhar para evitar a exposição do token a hosts não intencionados.
- O design de logout se torna complexo, pois as sessões da SPA, os cookies do BFF e as sessões do servidor de autorização devem estar todos vinculados.
Resumo
Uma maneira prática de lidar com tokens com segurança em aplicativos baseados em navegador é não colocá-los no navegador. O padrão BFF move as responsabilidades do cliente OAuth para o lado do servidor e passa apenas Cookies HttpOnly para o navegador. Isso impede o roubo de tokens mesmo que ocorra XSS. Ao dividir os papéis em um Agente OAuth e um Proxy OAuth, a segurança pode ser fortalecida enquanto se mantém a experiência de desenvolvimento da SPA.
