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 identity 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 isn't 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.
Common user journeys
Historically, many identity workflows relied on third-party cookies. The table lists some common user journeys and potential solutions for each of these that don't depend on third-party cookies. The following sections will explain the reasoning for these recommendations.
Recommended alternative APIs for common use cases
| User journey | Recommended APIs |
|---|---|
| Social sign-in |
For identity providers: implement FedCM For relying parties: reach out to your identity provider |
| Front Channel Logout | For identity providers: implement FedCM |
|
For identity providers or custom solutions: Related Website Sets |
|
| User profile management |
Storage Access API Related Website Sets CHIPS FedCM |
|
Storage Access API Related Website Sets CHIPS FedCM |
|
| Authentication |
Storage Access API FedCM Web Authentication API sciencePartitioned Popins |
| These scenarios generally don't have third-party cookie dependencies and aren't expected to be impacted. |
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.
Sign-in solutions
In this section, you will find more specific information on how those flows might be affected.
Third-party Single Sign On (SSO)
Third-party single sign-in (SSO) allows a user to authenticate with a single set of credentials on one platform, then access multiple applications and websites without having to re-enter their login information. 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.
If your solution relies on a third-party provider, it is possible that some minor changes, such as a library upgrade, may be necessary. The best approach is to seek guidance from the provider about how third-party cookie dependencies affect the solution and what approach they recommend for their service. Some providers will silently migrate away from third-party cookies, in which case relying parties don't need to update.
Multiple domains
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.
Some businesses can have multiple products hosted on different domains or subdomains. Such solutions may want to share the user session across those products, a scenario that may require accessing third-party cookies between multiple 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) and Storage Access API (SAA): RWS enables limited cross-site cookie access between a small group of related domains. With RWS, no user prompt is needed when requesting storage access with the Storage Access API. This allows for SSO on those RPs that are in the same RWS as the IdP. However, RWS only supports cross-site cookie access across a limited number of domains.
- Use Web Authentication API: the Web Authentication API allows relying parties (RPs) to register a limited set of related origins across which credentials can be created and used.
- If you are authenticating users across more than 5 associated domains, explore Federated Credentials Management (FedCM): 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.
Authentication from embeds
Suppose a 3-party-app.example iframe is embedded on top-level.example. On 3-party-app.example, the user can login either with 3-party-app.example credentials, or with another third-party provider.
The user clicks "login", and authenticates within the 3-party-app.example pop-up. The 3-party-app.example pop-up sets a first-party cookie. However, the 3-party-app.example iframe embedded on top-level.example is partitioned and can't access the cookie set in the first-party context on the 3-party-app.example.
The same problem would occur when a user is redirected from top-level.example to 3-party-app.example and back. The cookie is written in the first-party context of the 3-party-app.example site, but it is partitioned and not accessible within the 3-party-app.example iframe.
In cases where the user has visited the embedded origin in a top-level context, Storage Access API is a good solution.
To migrate away from the solutions that rely on third-party cookies, we recommend that the identity providers adopt the FedCM API and FedCM is called from inside embeds rather than pop-ups.
Another proposed solution for this flow, Partitioned Popins, is undergoing implementation.
Social Sign-in
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. Each federated identity provider will have its own implementation.
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 have removed reliance on third-party cookies., as the library will migrate silently to using FedCM for compatibility. We recommend testing your site with the third party cookie phaseout testing flag enabled and, if needed, using the FedCM migration checklist to prepare.
Access and modify user data from embeds
Embedded content is often used for user journeys like accessing or managing user profile or subscriptions data.
For example, a user might login to website.example, which embeds a subscriptions.example widget. This widget allows users to manage their data, such as subscribing to premium content or updating billing information. To modify user data, the embedded widget may need to access its own cookies while embedded on website.example. In the scenario where this data should be isolated towebsite.example, CHIPS can help ensure that the embed can access the information it needs. With CHIPS, subscriptions.example widget embedded on website.example won't have access to the user's subscription data on other websites.
Consider another case: a video from streaming.example is embedded on website.example, and the user has a premium streaming.example subscription, which the widget needs to know about to disable ads. If the same cookie needs to be accessed across multiple sites, consider using Storage Access API if the user has previously visited streaming.example as a top-level, and Related Website Sets if the set of the website.example owns the streaming.example.
From Chrome 131, FedCM is integrated with the Storage Access API. With this integration, when the user accepts the FedCM prompt, the browser will grant the IdP embed access to unpartitioned storage.
For more information on which API to choose to handle a particular user journey with embedded content, check the Embeds guide.
Front-channel logout
Front-channel logout is a mechanism that allows a user to log out of all related apps when the user logs out on one service. OIDC's Front-channel logout requires the IdP to embed several relying party (RP) iframes which rely on the RP's cookies.
If your solution relies on an identity provider, minor changes (such as a library upgrade) may be needed. For further guidance, reach out to your identity provider.
To address this use case, FedCM experimented with the logoutRPs feature. This allowed the IdP to log out any RP for which the user has previously approved the RP-IdP communication. This feature is no longer available, but we encourage you to have a look at the initial proposal and share your feedback with us if you're interested in or need this feature.
Other user journeys
User journeys that don't rely on third-party cookies shouldn't be affected by changes in how Chrome handles third-party cookies. The existing solutions, such as sign in, sign out, or account recovery within first party context, 2FA, should work as intended. Potential points of breakage have been described before. For more information on a particular API, check the API status page. Report any breakages experienced to goo.gle/report-3pc-broken. You can also submit a feedback form or file an issue on GitHub in the Privacy Sandbox developer support repository.
Audit your site
If your website implements one of the user journeys described in this guide, you need make sure your sites are prepared: audit your site for third-party cookie usage, test for breakage, and transition to the recommended solutions.