Chrome предлагает новый вариант выбора пользователя с помощью сторонних файлов cookie. Вам необходимо подготовить свой сайт для пользователей, которые предпочитают просматривать его без сторонних файлов cookie.
На этой странице вы найдете информацию о сценариях идентификации, которые, скорее всего, будут затронуты, а также ссылки на возможные решения.
Если ваш веб-сайт обрабатывает потоки только в одном домене и поддоменах, таких publisher.example и login.publisher.example , он не будет использовать межсайтовые файлы cookie, и на ваш процесс входа не повлияют третьи лица. изменения файлов cookie вечеринки.
Однако, если ваш сайт использует отдельный домен для входа, например, с помощью входа в Google или входа в Facebook , или вашему сайту необходимо использовать аутентификацию пользователя в нескольких доменах или поддоменах, есть вероятность, что вам придется внести изменения в свой сайт, чтобы обеспечить плавный переход от межсайтовых файлов cookie.
Типичные пути пользователя
Исторически сложилось так, что многие рабочие процессы идентификации полагались на сторонние файлы cookie. В таблице перечислены некоторые распространенные действия пользователя и потенциальные решения для каждого из них, которые не зависят от сторонних файлов cookie. В следующих разделах будут объяснены обоснования этих рекомендаций.
Рекомендуемые альтернативные API для распространенных случаев использования
| Путь пользователя | Рекомендуемые API |
|---|---|
| Вход через социальные сети | Для поставщиков удостоверений: внедрите FedCM. Для проверяющих сторон: обратитесь к своему поставщику удостоверений. |
| Выход из переднего канала | Для поставщиков удостоверений: внедрите FedCM. |
Для поставщиков удостоверений или индивидуальных решений: связанные наборы веб-сайтов. | |
| Управление профилями пользователей | API доступа к хранилищу Похожие наборы веб-сайтов ЧИПСЫ ФедКМ |
| API доступа к хранилищу Похожие наборы веб-сайтов ЧИПСЫ ФедКМ | |
| Аутентификация | API доступа к хранилищу ФедКМ API веб-аутентификации science Разделенные Попины |
| Эти сценарии обычно не имеют зависимостей от сторонних файлов cookie и, как ожидается, не будут затронуты. |
Протестируйте свой путь пользователя, связанный с идентификацией
Лучший способ проверить, влияют ли на ваш процесс входа изменения сторонних файлов cookie, — это пройти через процессы регистрации, восстановления пароля, входа и выхода с включенным флагом проверки сторонних файлов cookie .
Это контрольный список вещей, которые следует проверить, если вы ограничили использование сторонних файлов cookie:
- Регистрация пользователя: Создание новой учетной записи работает как положено. При использовании сторонних поставщиков удостоверений убедитесь, что регистрация новых учетных записей работает для каждой интеграции.
- Восстановление пароля: восстановление пароля работает должным образом: от веб-интерфейса до CAPTCHA и получения электронного письма для восстановления пароля.
- Вход в систему. Рабочий процесс входа в систему работает в одном домене и при переходе к другим доменам. Не забудьте протестировать каждую интеграцию входа в систему.
- Выход: процесс выхода работает должным образом, и пользователь остается в системе после выхода из системы.
Вам также следует убедиться, что другие функции сайта, требующие входа пользователя в систему, остаются работоспособными без межсайтовых файлов cookie, особенно если они включают загрузку межсайтовых ресурсов. Например, если вы используете CDN для загрузки изображений профиля пользователя, убедитесь, что это по-прежнему работает. Если у вас есть важные пользовательские действия, такие как оформление заказа, привязанные к входу в систему, убедитесь, что они продолжают работать.
Решения для входа
В этом разделе вы найдете более конкретную информацию о том, как эти потоки могут быть затронуты.
Сторонняя система единого входа (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 доступа к хранилищу. Это позволяет использовать единый вход на тех RP, которые находятся в том же RWS, что и IdP. Однако RWS поддерживает доступ к межсайтовым файлам cookie только в ограниченном количестве доменов.
- Использовать API веб-аутентификации : API веб-аутентификации позволяет проверяющим сторонам (RP) регистрировать ограниченный набор связанных источников, для которых можно создавать и использовать учетные данные.
- Если вы выполняете аутентификацию пользователей в более чем 5 связанных доменах, изучите 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, установленным в собственном контексте в 3-party-app.example .
Та же проблема может возникнуть, когда пользователь перенаправляется с top-level.example на 3-party-app.example и обратно. Файл cookie записывается в собственном контексте сайта 3-party-app.example , но он секционирован и недоступен в iframe 3-party-app.example .
В тех случаях, когда пользователь посетил встроенный источник в контексте верхнего уровня, API доступа к хранилищу является хорошим решением.
Чтобы перейти от решений, использующих сторонние файлы cookie, мы рекомендуем поставщикам удостоверений использовать API FedCM , а FedCM вызывается из встроенных файлов, а не из всплывающих окон.
Еще одно предлагаемое решение для этого потока — Partitioned Popins — находится на стадии реализации.
Вход через социальные сети
Кнопки входа, такие как «Войти через Google» , «Войти через Facebook» и «Войти через Twitter», являются верным признаком того, что ваш веб-сайт использует федеративный поставщик удостоверений . Каждый поставщик федеративных удостоверений будет иметь свою собственную реализацию.
Если вы используете устаревшую библиотеку платформы JavaScript для входа в Google , вы можете найти информацию о том, как перейти на более новую библиотеку 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 необходимо получить доступ на нескольких сайтах, рассмотрите возможность использования API доступа к хранилищу , если пользователь ранее streaming.example как верхний уровень, и наборы связанных веб-сайтов , если набор website.example владеет streaming.example .
Начиная с Chrome 131, FedCM интегрирован с API доступа к хранилищу . Благодаря этой интеграции, когда пользователь принимает приглашение FedCM, браузер предоставляет IdP доступ к неразделенному хранилищу.
Дополнительную информацию о том, какой API выбрать для обработки конкретного взаимодействия пользователя со встроенным контентом, можно найти в руководстве по встраиванию .
Выход из переднего канала
Выход из переднего канала — это механизм, который позволяет пользователю выходить из всех связанных приложений, когда пользователь выходит из одной службы. Для выхода из переднего канала OIDC требуется, чтобы поставщик удостоверений внедрил несколько iframe проверяющей стороны (RP), которые полагаются на файлы cookie RP.
Если ваше решение зависит от поставщика удостоверений, могут потребоваться незначительные изменения (например, обновление библиотеки). Для получения дальнейших инструкций обратитесь к своему поставщику удостоверений.
Чтобы решить эту проблему, FedCM экспериментировала с функцией logoutRPs . Это позволило IdP выйти из системы любого RP, для которого пользователь ранее одобрил связь RP-IdP. Эта функция больше недоступна, но мы рекомендуем вам ознакомиться с первоначальным предложением и поделиться с нами своим мнением, если вы заинтересованы в этой функции или нуждаетесь в ней.
Другие пути пользователя
На действия пользователя, не использующие сторонние файлы cookie, не должны влиять изменения в том, как Chrome обрабатывает сторонние файлы cookie. Существующие решения, такие как вход в систему, выход из системы или восстановление учетной записи в собственном контексте (2FA), должны работать должным образом. Потенциальные места поломки были описаны ранее. Для получения дополнительной информации о конкретном API посетите страницу статуса API . О любых поломках сообщайте по адресу goo.gle/report-3pc-broken . Вы также можете отправить форму обратной связи или сообщить о проблеме на GitHub в репозитории поддержки разработчиков Privacy Sandbox .
Аудит вашего сайта
Если на вашем веб-сайте реализован один из этапов взаимодействия с пользователем, описанных в этом руководстве, вам необходимо убедиться, что ваши сайты подготовлены : проверить свой сайт на предмет использования сторонних файлов cookie, протестировать их на предмет поломок и перейти к рекомендуемым решениям.