Chrome is proposing a new experience for user choice with third-party cookies. You need to prepare your site for users who choose to browse without third-party cookies.
On this page you will find information on the sign-in scenarios most likely to be affected, as well as references to possible solutions.
If your website only handles flows within the same domain and subdomains, such
as publisher.example and login.publisher.example, it won't use cross-site
cookies and your sign-in flow is not expected to be affected by third-party cookie changes.
However, if your site uses a separate domain for login, such as with Google Sign-in or Facebook Login, or your site needs to share user authentication across multiple domains or subdomains, there's a chance you will need to make changes to your site to ensure a smooth transition away from cross-site cookies.
Test your identity-related user journeys
The best way to test if your sign-in flow is affected by third-party cookie changes is to go through your registration, password recovery, sign-in and sign-out flows with the third party cookie testing flag enabled.
This is a checklist of things to check for once you've restricted third-party cookies:
- User registration: Creating a new account works as expected. If using third-party identity providers, check that registration of new accounts works for every integration.
- Password recovery: Password recovery works as expected, from the web UI, to CAPTCHAs, to receiving the password recovery email.
- Sign-in: The sign-in workflow works within the same domain and when navigating to other domains. Remember to test every sign-in integration.
- Sign-out: The sign-out process works as expected, and the user remains signed out after the sign-out flow.
You should also test that other site features that require user sign-in remain functional without cross-site cookies, especially if they involve loading cross-site resources. For example, if you use a CDN to load user profile images, ensure that this still works. If you have critical user journeys, such as checkout, gated on a sign-in, ensure that these continue to work.
In the next sections, you will find more specific information on how those flows might be affected.
Federated identity
Sign-in buttons like Sign in with Google, Facebook Login, and Log in with Twitter are a definitive sign that your website is using a federated identity provider. As each federated identity provider will have its own implementation, the best solution is to check your provider's documentation or reach out to them for further guidance.
If you are using the deprecated Google Sign-In JavaScript platform library, you can find information on how to migrate to the newer Google Identity Services library for authentication and authorization.
Most sites using the newer Google Identity Services library are ready for third-party cookie deprecation, as the library will migrate silently to using FedCM for compatibility. We recommend testing your site with the third party cookie testing flag enabled and, if needed, using the FedCM migration checklist to prepare.
Separate sign-in domain
Some websites use a different domain only for authenticating users that don't
qualify for same-site cookies, like a website using example.com for the main
site and login.example for the login flow, which might require accessing
third-party cookies to ensure that the user is authenticated across both
domains.
Possible migration paths for this scenario are:
- Update to use first-party ("same-site") cookies: Changing the website infrastructure so that the login flow is hosted on the same domain (or a subdomain) as the main site, which will only use first-party cookies. This may require higher effort, depending on how the infrastructure is set up.
- Use Related Website Sets (RWS): Related Website Sets enable limited cross-site cookie access between a small group of related domains. RWS is a Privacy Sandbox API built to support this use case. However, RWS only supports cross-site cookie access across a limited number of domains.
- If you are authenticating users across more than 5 associated domains, explore FedCM: Federated Credentials Management (FedCM) enables identity providers to rely on Chrome to handle identity-related flows without requiring third-party cookies. In your case, your "sign-in domain" could act as the FedCM identity provider and be used to authenticate users across your other domains.
Multiple domains
When a business has multiple products hosted on different domains or subdomains, it may want to share the user session across those products, a scenario that may require accessing third-party cookies between multiple domains.
In this scenario, hosting all products under the same domain is often impractical. Possible solutions in this case are:
- Use Related Website Sets: When cross-site cookie access is needed between a small group of related domains.
- Use Federation Credential Management (FedCM): When the number of domains is large, you could use a separate sign-in domain to act as an identity provider and authenticate users across your sites using FedCM.
Sign-in solutions
Third-party Single Sign On (SSO)
Due to the complexity of implementing an SSO solution, many companies opt into using a third-party solution provider, to share sign-in state between multiple origins. Examples of providers include Okta, Ping Identity, Google Cloud IAM or Microsoft Entra ID.
When using a third-party provider, the best approach is to seek guidance from the provider about how third-party cookie changes will affect the solution and what approach they recommend for their service.
Open source SSO solutions
Many companies maintaining their own SSO solutions will do so using established industry standards, such as OpenID Connect, OAuth or SAML, or established open source projects, like Keycloak, WSO2, Auth.js or Hydra.
We recommend checking the documentation for your provider to understand how cookie changes might affect their solution, and the best migration path for that specific solution.
Custom in-house solutions
If your sign-in solution falls into one of the use cases earlier and is built in-house, Prepare for phasing out third-party cookies explains in more detail how to audit your code and prepare for third party cookie changes.
Take action now!
If your website falls under one of the use cases, there are multiple solutions available to address any possible impact, from moving the authentication flow to the main domain so it only uses first-party cookies, using Related Website Sets to allow sharing cookies between a small number of domains, or leveraging Federation Credential Management.
The moment to audit your service and prepare for the third party cookie changes is now!