Cookies de terceiros podem ser bloqueados por restrições do navegador, configurações do usuário, flags do desenvolvedor ou política empresarial.
Seu site ou serviço precisa oferecer uma ótima experiência para todos os usuários, com ou sem cookies de terceiros.
Nesta página, você encontra informações sobre os cenários de identidade mais propensos a serem afetados, além de referências a possíveis soluções.
Se o site processar apenas fluxos no mesmo domínio e subdomínios, como
publisher.example e login.publisher.example, ele não usará cookies
entre sites, e não é esperado que o fluxo de login seja afetado por mudanças nos 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 precisar compartilhar a autenticação do usuário em vários domínios ou subdomínios, talvez seja necessário fazer mudanças 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 comuns do usuário e possíveis soluções para cada uma delas que não dependem de cookies de terceiros. As seções a seguir explicam o motivo dessas recomendações.
APIs alternativas recomendadas para casos de uso comuns
na tabela estão nos estágios iniciais de desenvolvimento. Seu feedback é valioso e vai ajudar a moldar o futuro deles. Compartilhe suas ideias sobre estas APIs: Pop-ins particionados.
| Jornada do usuário | APIs recomendadas |
|---|---|
| Login social |
Para provedores de identidade: implemente a FedCM Para partes confiáveis: entre em contato com seu provedor de identidade |
|
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 + SAA |
|
API Storage Access Conjuntos de sites relacionados CHIPS FedCM + SAA |
|
| 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. |
Teste as jornadas do usuário relacionadas à identidade
A melhor maneira de testar se o fluxo de login é afetado pelas mudanças nos 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 verificação de itens a serem verificados depois de restringir os cookies de terceiros:
- Registro de usuário:a criação de uma nova conta funciona normalmente. Se você usa provedores de identidade de terceiros, verifique se o registro de novas contas funciona para todas as integrações.
- Recuperação de senha:a recuperação de senha funciona como esperado, desde a interface da Web até os CAPTCHAs e o recebimento do e-mail de recuperação de senha.
- 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.
- Saída:o processo de saída funciona como esperado, e o usuário permanece desconectado após o fluxo de saída.
Teste também se outros recursos do site que exigem login do usuário continuam funcionando sem cookies entre sites, principalmente se envolverem o carregamento de recursos entre sites. Por exemplo, se você usa uma CDN para carregar imagens de perfil de usuário, verifique se isso ainda funciona. Se você tiver fluxos de usuários críticos, como finalização da compra, bloqueados por um login, verifique se eles continuam funcionando.
Soluções de login
Nesta seção, você vai 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 se autentique 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 de implementar uma solução de SSO, muitas empresas optam por usar um provedor de soluções terceirizado 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 sua solução depender de um provedor terceirizado, talvez seja necessário fazer algumas mudanças pequenas, 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 vão migrar silenciosamente dos cookies de terceiros. Nesse caso, as partes confiáveis não precisam fazer atualizações.
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 em ambos os
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.
Os possíveis caminhos de migração para esse cenário são:
- Atualize para usar cookies primários ("mesmo site"):mude a infraestrutura do site para que o fluxo de login seja hospedado no mesmo domínio (ou subdomínio) do site principal, que 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 API Storage Access (SAA):os RWS permitem acesso limitado a cookies entre sites em um pequeno grupo de domínios relacionados. Com o RWS, não é necessário solicitar ao usuário ao pedir acesso ao armazenamento com a API Storage Access. Isso permite o SSO nos RPs que estão no mesmo RWS que o IdP. No entanto, o RWS só é compatível com o acesso a cookies entre sites em um número limitado de domínios.
- Use a API Web Authentication:a API Web Authentication permite que as partes confiáveis (RPs) 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): a FedCM permite que os provedores de identidade confiem no Chrome para processar fluxos relacionados à identidade sem exigir cookies de terceiros. No seu caso, o "domínio de login" pode atuar como o provedor de identidade da FedCM e ser usado para autenticar usuários em seus 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 terceirizado.
O usuário clica em "login" e faz a autenticação no pop-up do 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 em top-level.example é particionado e
não pode acessar o conjunto de cookies no contexto primário em
3-party-app.example.
O mesmo problema ocorreria quando um usuário fosse redirecionado de top-level.example
para 3-party-app.example e vice-versa. O cookie é gravado no contexto primário do site 3-party-app.example, mas é particionado e não pode ser acessado 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 ela seja chamada de dentro de incorporações em vez de pop-ups.
Outra solução proposta para esse fluxo,os Popins particionados, está em implementação.
Login social
Botões de login como Fazer login com o Google, Login do 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 federada tem uma implementação própria.
Se você estiver usando a biblioteca da plataforma JavaScript do Login do Google descontinuada, saiba como migrar para a biblioteca mais recente dos Serviços de identificação do Google para autenticação e autorização.
A maioria dos sites que usam a biblioteca mais recente dos Serviços de Identificação do Google removeu a dependência de cookies de terceiros, já que a biblioteca vai migrar silenciosamente para usar a FedCM por compatibilidade. Recomendamos testar seu site com a flag de teste de descontinuação gradual de cookies de terceiros ativada e, se necessário, usar a lista de verificação de migração da FedCM para se preparar.
Acessar e modificar dados do usuário em incorporações
O conteúdo incorporado é usado com frequência em jornadas do usuário, como acessar ou gerenciar dados de perfil ou de assinaturas.
Por exemplo, um usuário pode fazer login no website.example, que incorpora um widget subscriptions.example. Com ele, os usuários podem gerenciar os dados,
como assinar conteúdo premium ou atualizar informações de faturamento. Para
modificar os dados do usuário, o widget incorporado pode precisar acessar os próprios cookies enquanto
estiver incorporado em website.example. No cenário em que esses dados precisam ser isolados para website.example, os CHIPS podem ajudar a garantir que a incorporação acesse as informações necessárias. Com o CHIPS, o widget subscriptions.example
incorporado em website.example não terá acesso aos dados de
assinatura do usuário em outros sites.
Considere outro caso: um vídeo de streaming.example está incorporado em 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 de nível superior e os Conjuntos de sites relacionados se o conjunto de website.example for proprietário de streaming.example.
A partir do Chrome 131, o FedCM será integrado à API Storage Access. Com essa integração, quando o usuário aceita a solicitação da FedCM, o navegador concede ao IdP acesso incorporado ao armazenamento não particionado.
Para mais informações sobre qual API escolher para lidar com uma jornada específica do usuário com conteúdo incorporado, consulte o guia de incorporações.
Outras jornadas do usuário
As jornadas do usuário que não dependem de cookies de terceiros não devem ser afetadas pelas mudanças na forma como o Chrome lida com esses cookies. 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 interrupção foram descritos anteriormente. Para mais informações sobre uma API específica, consulte a página de status da API.
Auditar seu site
Se o seu site implementar uma das jornadas do usuário descritas neste guia, verifique se os sites estão preparados: audite seu site quanto ao uso de cookies de terceiros, teste se há falhas e faça a transição para as soluções recomendadas.