Проверьте влияние изменений сторонних файлов cookie на рабочие процессы входа в систему.

Сторонние файлы cookie могут быть заблокированы ограничениями браузера, настройками пользователя , флагами разработчика или политикой предприятия .

Вам необходимо, чтобы ваш сайт или сервис обеспечивал удобство использования для всех ваших пользователей, независимо от того, доступны ли сторонние файлы cookie.

На этой странице вы найдете информацию о сценариях идентификации, которые, скорее всего, будут затронуты, а также ссылки на возможные решения.

Если ваш веб-сайт обрабатывает только потоки в пределах одного домена и поддоменов, например publisher.example и login.publisher.example , он не будет использовать межсайтовые файлы cookie, и ожидается, что ваш поток входа не будет затронут изменениями сторонних файлов cookie.

Однако если на вашем сайте для входа в систему используется отдельный домен, например, с помощью входа через Google или Facebook , или вашему сайту необходимо обеспечить общую аутентификацию пользователей на нескольких доменах или поддоменах, есть вероятность, что вам придется внести изменения на ваш сайт, чтобы обеспечить плавный переход от межсайтовых файлов cookie.

Обычные пути пользователя

Традиционно многие процессы идентификации полагались на сторонние файлы cookie. В таблице перечислены некоторые распространённые пользовательские сценарии и возможные решения для каждого из них, не зависящие от сторонних файлов cookie. В следующих разделах будут объяснены обоснования этих рекомендаций.

Рекомендуемые альтернативные API для распространенных случаев использования

В таблице представлены API, находящиеся на ранних стадиях разработки. Ваши отзывы очень ценны и помогут определить их будущее. Поделитесь своим мнением об этих API: Partitioned Popins .

Протестируйте пользовательские пути, связанные с идентификацией

Лучший способ проверить, влияют ли изменения сторонних файлов cookie на ваш процесс входа, — это пройти все этапы регистрации, восстановления пароля, входа и выхода с включенным флагом тестирования сторонних файлов cookie .

Вот контрольный список того, что следует проверить после ограничения сторонних файлов cookie:

• Регистрация пользователя: создание новой учётной записи работает как и ожидалось. При использовании сторонних поставщиков удостоверений убедитесь, что регистрация новых учётных записей работает для каждой интеграции.
• Восстановление пароля: Восстановление пароля работает так, как и ожидалось, от веб-интерфейса до CAPTCHA и получения электронного письма для восстановления пароля.
• Вход: Процесс входа работает как в пределах одного домена, так и при переходе на другие домены. Не забудьте протестировать каждую интеграцию входа.
• Выход из системы: процесс выхода из системы проходит так, как и ожидалось, и пользователь остается вне системы после выхода из системы.

Также следует проверить работоспособность других функций сайта, требующих входа пользователя, без межсайтовых файлов cookie, особенно если они предполагают загрузку межсайтовых ресурсов. Например, если вы используете CDN для загрузки изображений профиля пользователя, убедитесь, что эта функция работает. Если у вас есть критически важные пользовательские действия, такие как оформление заказа, связанные с входом в систему, убедитесь, что они продолжают работать.

Решения для входа

В этом разделе вы найдете более конкретную информацию о том, как эти потоки могут быть затронуты.

Сторонний единый вход (SSO)

Сторонняя система единого входа (SSO) позволяет пользователю проходить аутентификацию с помощью одного набора учётных данных на одной платформе, а затем получать доступ к нескольким приложениям и веб-сайтам без необходимости повторного ввода данных. Из-за сложности внедрения решения SSO многие компании предпочитают использовать сторонних поставщиков решений для обмена данными о состоянии входа между различными источниками. Примеры таких поставщиков включают Okta, Ping Identity, Google Cloud IAM или Microsoft Entra ID.

Если ваше решение зависит от стороннего поставщика, возможно, потребуется внести некоторые незначительные изменения, например, обновить библиотеку. Лучший подход — обратиться к поставщику за разъяснениями о том, как зависимости от сторонних файлов cookie влияют на решение и какой подход он рекомендует для своего сервиса. Некоторые поставщики автоматически отказываются от сторонних файлов cookie, и в этом случае проверяющим сторонам не нужно обновляться.

Несколько доменов

Некоторые веб-сайты используют другой домен только для аутентификации пользователей, которые не имеют права на файлы cookie того же сайта, например, веб-сайт, использующий example.com для основного сайта и login.example для потока входа, что может потребовать доступа к сторонним файлам cookie, чтобы гарантировать аутентификацию пользователя в обоих доменах.

У некоторых компаний несколько продуктов могут быть размещены на разных доменах или поддоменах. Такие решения могут предусматривать общий сеанс пользователя для всех этих продуктов, что может потребовать доступа к сторонним файлам cookie между несколькими доменами.

Возможные пути миграции для этого сценария:

• Обновление для использования основных файлов cookie («того же сайта») : изменение инфраструктуры веб-сайта таким образом, чтобы процесс входа в систему размещался в том же домене (или поддомене), что и основной сайт, который будет использовать только основные файлы cookie. Это может потребовать дополнительных усилий в зависимости от настройки инфраструктуры.
• Использование связанных наборов веб-сайтов (RWS) и API доступа к хранилищу (SAA) : RWS обеспечивает ограниченный межсайтовый доступ к файлам cookie между небольшой группой связанных доменов. При использовании RWS запрос доступа к хранилищу через API доступа к хранилищу не требует запроса пользователем. Это позволяет использовать единый вход (SSO) на тех RP, которые находятся в том же RWS, что и поставщик удостоверений. Однако RWS поддерживает межсайтовый доступ к файлам cookie только в ограниченном количестве доменов.
• Используйте API веб-аутентификации : API веб-аутентификации позволяет проверяющим сторонам (RP) регистрировать ограниченный набор связанных источников, в рамках которых могут создаваться и использоваться учетные данные.
• Если вы аутентифицируете пользователей более чем в пяти связанных доменах, изучите Federated Credentials Management (FedCM) : FedCM позволяет поставщикам удостоверений использовать Chrome для обработки потоков, связанных с идентификацией, без необходимости использования сторонних файлов cookie. В вашем случае ваш «домен входа» может выступать в качестве поставщика удостоверений FedCM и использоваться для аутентификации пользователей в других ваших доменах.

Аутентификация с помощью встроенных приложений

Предположим, что iframe 3-party-app.example встроен в top-level.example . В 3-party-app.example пользователь может войти либо с учётными данными 3-party-app.example , либо с помощью другого стороннего поставщика.

Пользователь нажимает кнопку «Войти» и проходит аутентификацию во всплывающем окне 3-party-app.example . Всплывающее окно 3-party-app.example устанавливает основной файл cookie. Однако iframe 3-party-app.example встроенный в top-level.example , разделен и не может получить доступ к файлу cookie, установленному в контексте основного файла cookie 3-party-app.example .

Та же проблема возникнет при перенаправлении пользователя с top-level.example на 3-party-app.example и обратно. Файл cookie записывается в контексте first-party сайта 3-party-app.example , но он секционирован и недоступен внутри iframe 3-party-app.example .

В случаях, когда пользователь посетил встроенный источник в контексте верхнего уровня, хорошим решением будет Storage Access API .

Чтобы отказаться от решений, которые полагаются на сторонние файлы cookie, мы рекомендуем поставщикам удостоверений использовать API FedCM и вызывать FedCM из внутренних встраиваемых систем, а не из всплывающих окон.

Другое предложенное решение для этого потока, Partitioned Popins , находится на стадии внедрения.

Вход через социальную сеть

Кнопки входа, такие как «Войти через Google» , «Войти через Facebook» и «Войти через Twitter» , однозначно указывают на то, что ваш сайт использует федеративный поставщик удостоверений . Каждый федеративный поставщик удостоверений имеет свою собственную реализацию.

Если вы используете устаревшую библиотеку платформы JavaScript Google Sign-In , вы можете найти информацию о том, как перейти на новую библиотеку Google Identity Services для аутентификации и авторизации.

Большинство сайтов, использующих новую библиотеку Google Identity Services, отказались от сторонних файлов cookie, поскольку библиотека будет автоматически перенесена на FedCM для обеспечения совместимости. Рекомендуем протестировать сайт с включенным флагом тестирования отказа от сторонних файлов cookie и, при необходимости, использовать контрольный список миграции FedCM для подготовки.

Доступ и изменение пользовательских данных из встроенных приложений

Встроенный контент часто используется для таких действий пользователя, как доступ или управление данными профиля пользователя или подписок.

Например, пользователь может войти на сайт website.example , где встроен виджет subscriptions.example . Этот виджет позволяет пользователям управлять своими данными, например, подписываться на премиум-контент или обновлять платёжную информацию. Для изменения пользовательских данных встроенному виджету может потребоваться доступ к собственным файлам cookie, встроенным на website.example . В случае, когда эти данные должны быть изолированы от website.example , CHIPS может гарантировать, что встроенный виджет получит доступ к необходимой ему информации. Благодаря CHIPS виджет subscriptions.example , встроенный на website.example не будет иметь доступа к данным о подписках пользователя на других сайтах.

Рассмотрим другой случай: видео с streaming.example встроено на website.example , и у пользователя есть премиум-подписка streaming.example , о которой виджет должен знать для отключения рекламы. Если к одному и тому же файлу cookie требуется доступ с нескольких сайтов, рассмотрите возможность использования Storage Access API , если пользователь ранее посещал streaming.example как сайт верхнего уровня, и Related Website Sets, если набор website.example владеет streaming.example .

Начиная с Chrome 131, FedCM интегрирован с API доступа к хранилищу . Благодаря этой интеграции, когда пользователь принимает запрос FedCM, браузер предоставляет поставщику удостоверений доступ к неразмеченному хранилищу.

Дополнительную информацию о том, какой API выбрать для обработки конкретного пользовательского опыта со встроенным контентом, см. в руководстве по встраиванию .

Другие пользовательские пути

Изменения в обработке сторонних файлов cookie в Chrome не должны влиять на действия пользователей, не зависящие от сторонних файлов cookie. Существующие решения, такие как вход, выход или восстановление аккаунта в контексте первой стороны (2FA), должны работать как задумано. Потенциальные уязвимости были описаны ранее. Подробнее о конкретном API см. на странице статуса API .

Аудит вашего сайта

Если на вашем сайте реализован один из путей пользователя, описанных в этом руководстве, вам необходимо убедиться, что ваши сайты подготовлены : провести аудит вашего сайта на предмет использования сторонних файлов cookie, протестировать его на наличие сбоев и перейти к рекомендуемым решениям.