Como lidar com o bloqueio de cookie 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 código 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 de Proteção de rastreamento inteligente ou ITP. O Chrome tem uma iniciativa de privacidade do navegador chamada Área Restrita de Privacidade. Essas iniciativas abrangem muitos esforços diferentes pelos navegadores em prol da privacidade do navegador 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. A Área Restrita de Privacidade 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 o MSAL.js 1.x. Consulte o guia de migração para mover um SPA do fluxo de código implícito para a 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.
• Sem uso de um segredo do cliente

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

• 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 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 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 o consentimento tenha sido concedido). Esse padrão significava que 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: 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 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 visita a página de logon, apresentar 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 práticas recomendadas para cache 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 a carga de JavaScript.
• Pop-ups
  • Se a experiência do usuário (UX) de um redirecionamento completo de página 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. O 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á as diretrizes aqui.

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 que eles vejam uma taxa mais alta 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 de token silencioso.

Como usar 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 ativados ou bloqueados no navegador.

A aquisição de token silenciosa 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 de origem cruzada e de mesma origem passando uma dica de usuário (conta) do aplicativo pai para o aplicativo em iframe. Para obter mais informações, confira 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 (script entre sites) 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 tokens de atualização roubado, os SPAs são tokens emitidos 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 para a página de logon.

Esse padrão de token de atualização de tempo de vida limitado 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 (a cada hora, em geral, 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 uniformemente por cookies de terceiros. Há 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 dispositivo corporativo gerenciado determinadas combinações de navegador e plataforma têm suporte para dispositivo de acesso condicional. 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 nesse cenário, pois os cookies permanecem no mesmo domínio (como login.contoso.com a app.contoso.com).

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

Ao assinar um usuário de um SPA, o MSAL.js recomenda usar o método de logoff 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 verão uma saída 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 para 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 saída da Microsoft e as práticas recomendadas 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 o MSAL.js, confira:

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