O Chrome está propondo uma nova experiência de escolha do usuário com cookies de terceiros. Você precisa preparar seu site para usuários que optam por navegar sem cookies de terceiros.
Nesta página, você encontra informações sobre os cenários de identidade mais propensos a ser afetados, além de referências a possíveis soluções.
Se o site só processa fluxos no mesmo domínio e subdomínios, como publisher.example e login.publisher.example, ele não vai usar cookies entre sites, e o fluxo de login não será afetado por mudanças de cookies de terceiros.
No entanto, se o site usar um domínio separado para login, como o Login do Google ou o Login do Facebook, ou se ele precisar compartilhar a autenticação do usuário em vários domínios ou subdomínios, talvez seja necessário fazer alterações no site para garantir uma transição tranquila dos cookies entre sites.
Jornadas comuns dos usuários
Historicamente, muitos fluxos de trabalho de identidade dependiam de cookies de terceiros. A tabela lista algumas jornadas de usuários comuns e possíveis soluções para cada uma delas que não dependem de cookies de terceiros. As seções a seguir explicam o raciocínio por trás dessas recomendações.
APIs alternativas recomendadas para casos de uso comuns
| Jornada do usuário | APIs recomendadas |
|---|---|
| Login com redes sociais |
Para provedores de identidade: implemente o FedCM Para partes confiáveis: entre em contato com seu provedor de identidade |
| Sair do canal principal | Para provedores de identidade: implementar o FedCM |
|
Para provedores de identidade ou soluções personalizadas: conjuntos de sites relacionados |
|
| Gerenciamento de perfis de usuário |
API Storage Access Conjuntos de sites relacionados CHIPS FedCM |
|
API Storage Access Conjuntos de sites relacionados CHIPS FedCM |
|
| Authentication |
API Storage Access FedCM API Web Authentication sciencePop-ups particionados |
| Esses cenários geralmente não têm dependências de cookies de terceiros e não devem ser afetados. |
Testar as jornadas dos usuários relacionadas à identidade
A melhor maneira de testar se o fluxo de login é afetado por mudanças de cookies de terceiros é passar pelos fluxos de registro, recuperação de senha, login e logout com a flag de teste de cookies de terceiros ativada.
Esta é uma lista de itens a serem verificados depois de restringir cookies de terceiros:
- Registro de usuário: a criação de uma nova conta funciona como esperado. Se você estiver usando provedores de identidade de terceiros, verifique se o registro de novas contas funciona para cada integração.
- Recuperação de senha:a recuperação de senha funciona conforme o esperado, desde a interface da Web até os CAPTCHAs até o recebimento do e-mail de recuperação de senha.
- Fazer login: o fluxo de trabalho de login funciona no mesmo domínio e ao navegar para outros domínios. Não se esqueça de testar todas as integrações de login.
- Sair: o processo de saída funciona como esperado, e o usuário permanece desconectado após o fluxo de saída.
Você também precisa testar se outros recursos do site que exigem login do usuário continuam funcionais sem cookies entre sites, especialmente se eles envolvem o carregamento de recursos entre sites. Por exemplo, se você usa um CDN para carregar imagens do perfil do usuário, confira se ele ainda funciona. Se você tiver jornadas de usuário críticas, como finalização de compra, restritas a um login, verifique se elas continuam funcionando.
Soluções de login
Nesta seção, você encontrará informações mais específicas sobre como esses fluxos podem ser afetados.
Logon único (SSO) de terceiros
O logon único (SSO) de terceiros permite que um usuário faça a autenticação com um único conjunto de credenciais em uma plataforma e acesse vários aplicativos e sites sem precisar inserir novamente as informações de login. Devido à complexidade da implementação de uma solução de SSO, muitas empresas optam por usar um provedor de soluções de terceiros para compartilhar o estado de login entre várias origens. Exemplos de provedores incluem Okta, Ping Identity, Google Cloud IAM ou Microsoft Entra ID.
Se a solução depender de um provedor de terceiros, talvez seja necessário fazer algumas mudanças menores, como um upgrade de biblioteca. A melhor abordagem é buscar orientação do provedor sobre como as dependências de cookies de terceiros afetam a solução e qual abordagem ele recomenda para o serviço. Alguns provedores migram silenciosamente de cookies de terceiros. Nesse caso, as partes confiáveis não precisam atualizar.
Vários domínios
Alguns sites usam um domínio diferente apenas para autenticar usuários que não se qualificam para cookies do mesmo site, como um site que usa example.com para o site principal e login.example para o fluxo de login, o que pode exigir o acesso a cookies de terceiros para garantir que o usuário seja autenticado nos dois domínios.
Algumas empresas podem ter vários produtos hospedados em domínios ou subdomínios diferentes. Essas soluções podem querer compartilhar a sessão do usuário entre esses produtos, um cenário que pode exigir o acesso a cookies de terceiros entre vários domínios.
As possíveis rotas de migração para esse cenário são:
- Atualização para usar cookies primários ("mesmo site"):mudar a infraestrutura do site para que o fluxo de login fique hospedado no mesmo domínio (ou subdomínio) do site principal, que vai usar apenas cookies primários. Isso pode exigir mais esforço, dependendo de como a infraestrutura está configurada.
- Use conjuntos de sites relacionados (RWS) e a API Storage Access (SAA): o RWS permite o acesso limitado de cookies entre sites entre um pequeno grupo de domínios relacionados. Com o RWS, nenhum comando do usuário é necessário ao pedir acesso ao armazenamento com a API Storage Access. Isso permite o SSO nos RPs que estão no mesmo RWS do IdP. No entanto, o RWS só oferece suporte ao acesso de cookies entre sites em um número limitado de domínios.
- Usar a API Web Authentication: a API Web Authentication permite que as partes confiáveis (RPs, na sigla em inglês) registrem um conjunto limitado de origens relacionadas em que as credenciais podem ser criadas e usadas.
- Se você estiver autenticando usuários em mais de cinco domínios associados, conheça o Gerenciamento de credenciais federadas (FedCM, na sigla em inglês): o FedCM permite que os provedores de identidade confiem no Chrome para processar fluxos relacionados a identidade sem exigir cookies de terceiros. No seu caso, o "domínio de login" pode atuar como o provedor de identidade do FedCM e ser usado para autenticar usuários em outros domínios.
Autenticação de incorporações
Suponha que um iframe 3-party-app.example esteja incorporado em top-level.example. No 3-party-app.example, o usuário pode fazer login com as credenciais do 3-party-app.example ou com outro provedor de terceiros.
O usuário clica em "Fazer login" e faz a autenticação no pop-up 3-party-app.example. O pop-up 3-party-app.example define um cookie primário. No entanto, o iframe 3-party-app.example incorporado no top-level.example é particionado e não pode acessar o cookie definido no contexto primário no 3-party-app.example.
O mesmo problema ocorreria quando um usuário fosse redirecionado de top-level.example para 3-party-app.example e depois voltasse. O cookie é gravado no contexto primário do site 3-party-app.example, mas é particionado e não é acessível no iframe 3-party-app.example.
Nos casos em que o usuário visitou a origem incorporada em um contexto de nível superior, a API Storage Access é uma boa solução.
Para migrar das soluções que dependem de cookies de terceiros, recomendamos que os provedores de identidade adotem a API FedCM e que o FedCM seja chamado de incorporações em vez de pop-ups.
Outra solução proposta para este fluxo, pop-ups particionados, está em implementação.
Login em redes sociais
Botões de login como Fazer login com o Google, Fazer login com o Facebook e Fazer login com o Twitter são um sinal definitivo de que seu site está usando um provedor de identidade federado. Cada provedor de identidade federado terá a própria implementação.
Se você estiver usando a biblioteca da plataforma JavaScript do Login do Google descontinuada, confira informações sobre como migrar para a nova biblioteca dos Serviços de Identificação do Google para autenticação e autorização.
A maioria dos sites que usa a biblioteca mais recente dos Serviços de Identificação do Google não depende mais de cookies de terceiros, já que a biblioteca vai migrar silenciosamente para o uso do FedCM para compatibilidade. Recomendamos testar seu site com a flag de teste de desativação de cookies de terceiros ativada e, se necessário, usar a lista de verificação de migração do FedCM para se preparar.
Acessar e modificar dados do usuário de incorporações
O conteúdo incorporado é usado com frequência para jornadas do usuário, como acessar ou gerenciar dados de perfil ou assinaturas do usuário.
Por exemplo, um usuário pode fazer login no website.example, que incorpora um widget subscriptions.example. Esse widget permite que os usuários gerenciem os dados, como assinar conteúdo premium ou atualizar as informações de faturamento. Para modificar os dados do usuário, o widget incorporado pode precisar acessar os próprios cookies enquanto estiver incorporado no website.example. No cenário em que esses dados precisam ser isolados para website.example, o CHIPS pode ajudar a garantir que a incorporação possa acessar as informações necessárias. Com o CHIPS, o widget subscriptions.example incorporado no website.example não terá acesso aos dados de assinatura do usuário em outros sites.
Considere outro caso: um vídeo do streaming.example está incorporado no website.example, e o usuário tem uma assinatura premium do streaming.example, que o widget precisa conhecer para desativar os anúncios. Se o mesmo cookie precisar ser acessado em vários sites, use a API Storage Access se o usuário já tiver visitado streaming.example como nível superior e os Conjuntos de sites relacionados se o conjunto de website.example for proprietário do streaming.example.
No Chrome 131, o FedCM é integrado à API Storage Access. Com essa integração, quando o usuário aceita a solicitação do FedCM, o navegador concede ao IdP acesso de incorporação ao armazenamento não particionado.
Para mais informações sobre qual API escolher para processar uma jornada de usuário específica com conteúdo incorporado, consulte o guia de incorporações.
Logout do canal principal
O logout de front-channel é um mecanismo que permite que o usuário saia de todos os apps relacionados quando sair de um serviço. O deslogamento do canal principal do OIDC exige que o IdP incorpore vários iframes de parte confiável (RP, na sigla em inglês) que dependem dos cookies do RP.
Se a solução depender de um provedor de identidade, talvez seja necessário fazer pequenas mudanças, como um upgrade de biblioteca. Para receber mais orientações, entre em contato com seu provedor de identidade.
Para resolver esse caso de uso, a FedCM testou o recurso logoutRPs. Isso permitiu que o IdP desconectasse qualquer RP para o qual o usuário já havia aprovado a comunicação RP-IdP. Esse recurso não está mais disponível, mas recomendamos que você analise a proposta inicial e compartilhe seu feedback se tiver interesse ou precisar desse recurso.
Outras jornadas do usuário
As jornadas do usuário que não dependem de cookies de terceiros não são afetadas pelas mudanças na forma como o Chrome processa cookies de terceiros. As soluções atuais, como fazer login, sair ou recuperar a conta no contexto próprio, 2FA, devem funcionar como esperado. Os possíveis pontos de falha já foram descritos antes. Para mais informações sobre uma API específica, consulte a página de status da API. Informe as falhas ocorridas em goo.gle/report-3pc-broken. Também é possível enviar um formulário de feedback ou registrar um problema no GitHub no repositório de suporte a desenvolvedores da Sandbox de privacidade.
Auditar seu site
Se o seu site implementa uma das jornadas de usuário descritas neste guia, verifique se ele está preparado: audite o uso de cookies de terceiros, teste a quebra e faça a transição para as soluções recomendadas.