Como lidar com o bloqueio de cookies de terceiros em navegadores

Muitos navegadores bloqueiam cookies de terceiros, cookies em solicitações a domínios que não sejam o domínio mostrado na barra de endereços do navegador. Esses cookies também são conhecidos como cookies entre domínios. Isso interrompe o fluxo implícito e exige novos padrões de autenticação para conectar os usuários com êxito. Na plataforma de identidade da Microsoft, usamos o fluxo de autorização com PKCE (Chave de Prova para Troca de Código) e tokens de atualização para manter os usuários conectados quando cookies de terceiros são bloqueados. Esse fluxo de código de autorização com a abordagem de Chave de Prova para Troca de Código é recomendado em vez do fluxo implícito.

O que é ITP (Proteção contra Rastreamento Inteligente) e o que é Privacy Sandbox?

O Apple Safari tem um recurso de proteção de privacidade por padrão chamado Proteção contra Rastreamento Inteligente ou ITP. O Chrome tem uma iniciativa de privacidade do navegador chamada Privacy Sandbox. Essas iniciativas abrangem muitos esforços diferentes dos navegadores em prol da privacidade e têm linhas do tempo diferentes. Ambos os esforços bloqueiam cookies de "terceiros" em solicitações que cruzam domínios, com Safari e Brave bloqueando cookies de terceiros por padrão. O Chrome anunciou recentemente que começará a bloquear cookies de terceiros por padrão. O Privacy Sandbox inclui alterações no armazenamento particionado, bem como bloqueio de cookies de terceiros.

Uma forma comum de rastreamento de usuário é feita carregando um iframe para um site de terceiros em segundo plano e usando cookies para correlacionar o usuário pela Internet. Infelizmente, esse padrão também é a maneira padrão de implementar o fluxo implícito em aplicativos de página única (SPAs). Um navegador que bloqueia cookies de terceiros para proteger a privacidade do usuário também pode bloquear a funcionalidade de um SPA. O uso do fluxo implícito em SPAs não é mais recomendado devido ao bloqueio de cookies de terceiros e aos riscos de segurança associados a ele.

A solução descrita neste artigo funciona em todos esses navegadores ou em qualquer lugar em que os cookies de terceiros são bloqueados.

Visão geral da solução

Para continuar autenticando os usuários no SPAs, os desenvolvedores de aplicativos devem usar o fluxo de código de autorização. No fluxo do código de autenticação, o provedor de identidade emite um código, e o SPA resgata o código para um token de acesso e um token de atualização. Quando o aplicativo requer novos tokens, ele pode usar o fluxo de token de atualização para obter novos tokens. A MSAL (Biblioteca de Autenticação da Microsoft) para JavaScript v2.0 ou superior implementa o fluxo do código de autorização para SPAs e, com atualizações secundárias, é uma substituição pronta para a MSAL.js 1.x. Consulte o guia de migração para mover um SPA do fluxo de código implícito para o de autenticação.

Para a plataforma de identidade da Microsoft, SPAs e clientes nativos seguem diretrizes de protocolo semelhantes:

• Uso de um desafio de código PKCE
  • O PKCE é necessário para SPAs na plataforma de identidade da Microsoft. O PKCE é recomendado para clientes nativos e confidenciais.
• Não usa um segredo do cliente

Os SPAs têm mais duas restrições:

• O URI de redirecionamento deve ser marcado como o tipo spa para habilitar CORS em pontos de extremidade de logon.
• Os tokens de atualização emitidos pelo fluxo de código de autorização para URIs de redirecionamento spa têm uma vida útil de 24 horas em vez de 90 dias.

Implicações de desempenho e UX

Alguns aplicativos que usam o fluxo implícito tentam iniciar sessão sem redirecionamento abrindo um iframe de logon usando prompt=none. Na maioria dos navegadores, essa solicitação responde com tokens para o usuário conectado no momento (supondo que houve consentimento). Com esse padrão, os aplicativos não precisavam de um redirecionamento de página completa para conectar o usuário, melhorando o desempenho e a experiência do usuário, visto que, ao visitar a página da Web, o usuário já estava conectado. Como prompt=none em um iframe não é mais uma opção quando cookies de terceiros são bloqueados, os aplicativos devem ajustar seus padrões de entrada para ter um código de autorização emitido.

Sem cookies de terceiros, há duas maneiras de realizar a entrada:

• Redirecionamentos de página completa
  • No primeiro carregamento do SPA, redirecione o usuário para a página de entrada se não houver sessão (ou se a sessão estiver expirada). O navegador do usuário acessa a página de logon, apresenta os cookies que contêm a sessão do usuário e é redirecionado de volta para o aplicativo com o código e os tokens em um fragmento.
  • O redirecionamento faz o SPA ser carregado duas vezes. Siga as melhores práticas de caching de SPAs para que o aplicativo não seja baixado completamente duas vezes.
  • Tenha uma sequência de pré-carregamento no aplicativo que verifica uma sessão de logon e redireciona para a página de logon antes que o aplicativo seja totalmente descompactado e execute o payload de JavaScript.
• Pop-ups
  • Se a experiência do usuário (UX) de um redirecionamento de página completa não funcionar para o aplicativo, use um pop-up para lidar com a autenticação.
  • Quando o pop-up termina o redirecionamento para o aplicativo após a autenticação, o código no manipulador de redirecionamento armazenará o código de autenticação e os tokens no armazenamento local para o aplicativo usar. A MSAL.js dá suporte a pop-ups para autenticação, como a maioria das bibliotecas.
  • Os navegadores estão diminuindo o suporte para pop-ups; portanto, eles podem não ser a opção mais confiável. A interação do usuário com o SPA antes de criar o pop-up pode ser necessária para atender aos requisitos do navegador.

A Apple descreve um método pop-up como uma correção de compatibilidade temporária para dar à janela original o acesso a cookies de terceiros. Embora a Apple possa remover essa transferência de permissões no futuro, ela não afetará estas diretrizes.

Aqui, o pop-up está sendo usado como uma navegação de primeira entidade para a página de logon, para que uma sessão seja encontrada e um código de autenticação possa ser fornecido. Isso deve continuar funcionando no futuro.

Os desenvolvedores podem continuar usando prompt=none com a expectativa de encontrar uma maior taxa de erros de interacion_required quando cookies de terceiros são bloqueados. A recomendação é sempre ter um fallback de método interativo, se ocorrerem falhas durante a aquisição silenciosa de token.

Uso de iframes

Um padrão comum em aplicativos Web é usar um iframe para inserir um aplicativo dentro de outro: o quadro de nível superior lida com a autenticação do usuário e o aplicativo hospedado no iframe pode confiar que o usuário está conectado, buscando tokens silenciosamente usando o fluxo implícito. No entanto, há algumas ressalvas para essa suposição, independentemente de os cookies de terceiros estarem habilitados ou bloqueados no navegador.

A aquisição silenciosa de token não funciona mais quando cookies de terceiros são bloqueados. O aplicativo inserido no iframe deve alternar para o uso de pop-ups para acessar a sessão do usuário, pois ele não pode navegar até a página de logon dentro de um quadro inserido.

Você pode obter o logon único entre aplicativos em iframe e aplicativos pai com acesso à API de script JavaScript entre origens e de mesma origem passando uma dica de usuário (conta) do aplicativo pai para o aplicativo em iframe. Para obter mais informações, consulte Como usar a MSAL.js em aplicativos em iframe no repositório MSAL.js no GitHub.

Implicações de segurança de tokens de atualização no navegador

Os ataques XSS (cross-site scripting) ou pacotes JS comprometidos podem roubar o token de atualização e usá-lo remotamente até que ele expire ou seja revogado. Os desenvolvedores de aplicativos são responsáveis por reduzir o risco do aplicativo para cross-site scripting. Para minimizar o risco de roubo de tokens de atualização, os SPAs são tokens emitidos com validade de apenas 24 horas. Após 24 horas, o aplicativo deve adquirir um novo código de autorização por meio de uma visita de quadro de nível superior à página de logon.

Esse padrão de token de atualização de vida útil limitada foi escolhido como um equilíbrio entre a segurança e a UX degradada. Sem tokens de atualização ou cookies de terceiros, o fluxo do código de autorização (conforme recomendado pelo rascunho de práticas recomendadas de segurança do OAuth mais recentes) torna-se oneroso quando são necessários tokens novos ou adicionais. Um redirecionamento de página completo ou um pop-up é necessário para cada token único sempre que ele expira (geralmente a cada hora para tokens da plataforma de identidade da Microsoft).

Mitigações específicas do tipo de usuário

Nem todos os usuários e aplicativos são afetados da mesma forma por cookies de terceiros. Há alguns cenários em que, devido à arquitetura ou ao gerenciamento de dispositivos, é possível fazer chamadas silenciosas para renovar tokens sem cookies de terceiros.

Para cenários de dispositivo corporativo gerenciado, determinadas combinações de navegador e plataforma têm suporte para acesso condicional de dispositivo. A aplicação da identidade do dispositivo minimiza a necessidade de cookies de terceiros, pois o estado de autenticação pode vir do dispositivo em vez do navegador.

Para cenários do aplicativo Azure AD B2C, os clientes podem configurar um domínio de logon personalizado para corresponder ao domínio do aplicativo. Os navegadores não bloqueariam cookies de terceiros nesse cenário, pois os cookies permanecem no mesmo domínio (como login.contoso.com a app.contoso.com).

Limitações no logoff de canal frontal sem cookies de terceiros

Ao desconectar um usuário de um SPA, a recomendação da MSAL.js é usar o método de logoff de pop-up ou redirecionamento. Embora isso limpe a sessão de autenticação no servidor e no armazenamento do navegador, há um risco de que, sem acesso a cookies de terceiros, nem todos os aplicativos federados sejam desconectados ao mesmo tempo. Essa é uma limitação conhecida da especificação de logoff de canal frontal do OpenID 1.0. Para os usuários, isso significa que os tokens de acesso existentes de outros aplicativos para o mesmo usuário permanecerão válidos até a expiração deles. Um usuário pode fazer logoff do aplicativo A na guia A, mas o aplicativo B na guia B ainda aparecerá como conectado pelo tempo válido restante do token de acesso. Quando o token do aplicativo B expira e uma chamada é feita ao servidor para obter um novo token, o aplicativo B recebe uma resposta do servidor de que a sessão expirou e solicita que o usuário se autentique.

A página de desconexão da Microsoft e as melhores práticas de privacidade da Internet recomendam que os usuários fechem todas as janelas do navegador depois de fazer logoff de um aplicativo.

Próximas etapas

Para obter mais informações sobre o fluxo de código de autorização e a MSAL.js, consulte:

• Fluxo do código de autorização.
• Guia de início rápido da MSAL.js 2.0.