Como lidar com o bloqueio de cookies de terceiros em navegadores

Muitos navegadores bloqueiam cookies de terceiros, cookies em solicitações para domínios diferentes do domínio mostrado na barra de endereço do navegador. Estes cookies também são conhecidos como cookies entre domínios. Esse bloco quebra o fluxo implícito e requer novos padrões de autenticação para entrar com êxito nos usuários. Na plataforma de identidade da Microsoft, usamos o fluxo de código de autorização com PKCE (Proof Key for Code Exchange) 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 Proof Key for Code Exchange é recomendado sobre o fluxo implícito.

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

O Apple Safari tem um recurso de proteção de privacidade por padrão chamado Intelligent Tracking Protection, ou ITP. O Chrome tem uma iniciativa de privacidade do navegador denominada Sandbox de Privacidade. Essas iniciativas abrangem muitos esforços diferentes de privacidade dos navegadores e têm cronogramas diferentes. Ambos os esforços bloqueiam cookies de "terceiros" em solicitações que cruzam domínios, com o Safari e o Brave bloqueando cookies de terceiros por padrão. O Chrome anunciou recentemente que vai começar a bloquear cookies de terceiros por predefinição. O Privacy Sandbox inclui alterações no armazenamento particionado, bem como o bloqueio de cookies de terceiros.

Uma forma comum de rastreamento do usuário é feita carregando um iframe para site de terceiros em segundo plano e usando cookies para correlacionar o usuário na 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 onde os cookies de terceiros sejam bloqueados.

Descrição geral da solução

Para continuar autenticando usuários em SPAs, os desenvolvedores de aplicativos devem usar o fluxo de código de autorização. No fluxo de 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. Microsoft Authentication Library (MSAL) para JavaScript v2.0 e superior, implementa o fluxo de código de autorização para SPAs e, com pequenas atualizações, é um substituto drop-in para MSAL.js 1.x. Consulte o guia de migração para mover um SPA do fluxo de código implícito para o fluxo de código de autenticação.

Para a plataforma de identidade da Microsoft, SPAs e clientes nativos seguem orientações de protocolo semelhantes:

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

As ZPE têm mais duas restrições:

• O URI de redirecionamento deve ser marcado como tipo spa para habilitar o CORS nos pontos de extremidade de login.
• Os tokens de atualização emitidos por meio do fluxo de código de autorização para spa redirecionar URIs têm um tempo de vida de 24 horas em vez de um tempo de vida de 90 dias.

Implicações de desempenho e UX

Alguns aplicativos que usam o fluxo implícito tentam entrar sem redirecionar, abrindo um iframe de login usando prompt=none. Na maioria dos navegadores, essa solicitação responde com tokens para o usuário conectado no momento (supondo que o consentimento seja concedido). Esse padrão significava que os aplicativos não precisavam de um redirecionamento de página inteira para fazer login no usuário, melhorando o desempenho e a experiência do usuário - o usuário visita a página da Web e já está 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 login para ter um código de autorização emitido.

Sem cookies de terceiros, existem duas formas de iniciar sessão:

• Redirecionamentos de página inteira
  • Na primeira carga do SPA, redirecione o usuário para a página de entrada se nenhuma sessão já existir (ou se a sessão tiver expirado). O navegador do usuário visita a página de login, apresenta os cookies que contêm a sessão do usuário e, em seguida, é redirecionado de volta para o aplicativo com o código e os tokens em um fragmento.
  • O redirecionamento resulta no carregamento do SPA duas vezes. Siga as práticas recomendadas para armazenamento em cache de SPAs para que o aplicativo não seja baixado na íntegra duas vezes.
  • Considere ter uma sequência de pré-carregamento no aplicativo que verifica se há uma sessão de login e redireciona para a página de login antes que o aplicativo descompacte totalmente e execute a carga útil JavaScript.
• Pop-ups
  • Se a experiência do usuário (UX) de um redirecionamento de página inteira não funcionar para o aplicativo, considere usar um pop-up para lidar com a autenticação.
  • Quando o pop-up terminar de redirecionar 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. MSAL.js suporta pop-ups para autenticação, assim como a maioria das bibliotecas.
  • Os navegadores estão diminuindo o suporte para pop-ups, então 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 satisfazer os requisitos do navegador.

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

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

Os desenvolvedores podem continuar a usar prompt=none com a expectativa de ver uma taxa maior de erros de interacion_required quando os 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 tokens.

Usando iframes

Um padrão comum em aplicativos Web é usar um iframe para incorporar um aplicativo dentro de outro: o quadro de nível superior manipula 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 a essa suposição, independentemente de os cookies de terceiros estarem habilitados ou bloqueados no navegador.

A aquisição silenciosa de tokens não funciona mais quando cookies de terceiros são bloqueados - o aplicativo incorporado no iframe deve alternar para usar pop-ups para acessar a sessão do usuário, pois não pode navegar para a página de login dentro de um quadro incorporado.

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

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

Ataques de script entre sites (XSS) 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 de seus aplicativos para scripts entre sites. Para minimizar o risco de tokens de atualização roubados, os SPAs são emitidos tokens válidos por 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 login.

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

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

Nem todos os utilizadores e aplicações são uniformemente afetados por cookies de terceiros. Existem alguns cenários em que, devido à arquitetura ou ao gerenciamento de dispositivos, chamadas silenciosas para renovar tokens podem ser feitas sem cookies de terceiros.

Para cenários de dispositivos empresariais gerenciados, 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 de aplicativo do 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 neste cenário, pois os cookies permanecem no mesmo domínio (como login.contoso.com para app.contoso.com).

Limitações no Logout Front-Channel sem cookies de terceiros

Ao sair de um SPA, MSAL.js recomenda usar o método pop-up ou redirecionar logout. Embora isso limpe a sessão de autenticação no servidor e no armazenamento do navegador, há o risco de que, sem acesso a cookies de terceiros, nem todos os aplicativos federados vejam uma saída ao mesmo tempo. Esta é uma limitação conhecida da especificação OpenID Front-Channel Logout 1.0. O que isso significa para os usuários é que os tokens de acesso existentes para outros aplicativos para o mesmo usuário continuarão a ser válidos até o tempo de expiração. Um usuário pode sair 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 informando que a sessão expirou e solicita que o usuário se autentique.

A página de saída da Microsoft e as práticas recomendadas de privacidade na Internet recomendam que os usuários fechem todas as janelas do navegador depois de sair de um aplicativo.

Próximos passos

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

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