Chrome предлагает новый опыт выбора пользователем с помощью сторонних файлов cookie. Вам необходимо подготовить свой сайт для пользователей, которые предпочитают просматривать его без сторонних файлов cookie.
На этой странице вы найдете информацию о сценариях входа, которые, скорее всего, будут затронуты, а также ссылки на возможные решения.
Если ваш веб-сайт обрабатывает потоки только в одном домене и поддоменах, таких publisher.example и login.publisher.example , он не будет использовать межсайтовые файлы cookie, и на ваш процесс входа не повлияет сторонняя сторона. изменения файлов cookie.
Однако, если ваш сайт использует отдельный домен для входа, например, с помощью входа в Google или входа в Facebook , или вашему сайту необходимо использовать аутентификацию пользователя в нескольких доменах или поддоменах, есть вероятность, что вам придется внести изменения в свой сайт, чтобы обеспечить плавный переход от межсайтовых файлов cookie.
Протестируйте свой путь пользователя, связанный с идентификацией
Лучший способ проверить, влияют ли на ваш процесс входа изменения сторонних файлов cookie, — это пройти через процессы регистрации, восстановления пароля, входа и выхода с включенным флагом проверки сторонних файлов cookie .
Это контрольный список того, что следует проверить, если вы ограничили использование сторонних файлов cookie:
- Регистрация пользователя: Создание новой учетной записи работает как положено. При использовании сторонних поставщиков удостоверений убедитесь, что регистрация новых учетных записей работает для каждой интеграции.
- Восстановление пароля: восстановление пароля работает должным образом: от веб-интерфейса до CAPTCHA и получения электронного письма для восстановления пароля.
- Вход в систему. Рабочий процесс входа в систему работает в одном домене и при переходе к другим доменам. Не забудьте протестировать каждую интеграцию входа в систему.
- Выход: процесс выхода работает должным образом, и пользователь остается в системе после выхода из системы.
Вам также следует убедиться, что другие функции сайта, требующие входа пользователя в систему, остаются работоспособными без межсайтовых файлов cookie, особенно если они включают загрузку межсайтовых ресурсов. Например, если вы используете CDN для загрузки изображений профиля пользователя, убедитесь, что это по-прежнему работает. Если у вас есть важные пользовательские действия, такие как оформление заказа, привязанные к входу в систему, убедитесь, что они продолжают работать.
В следующих разделах вы найдете более конкретную информацию о том, как эти потоки могут быть затронуты.
Федеративная идентичность
Кнопки входа, такие как «Войти через Google» , «Войти через Facebook» и «Войти через Twitter», являются явным признаком того, что ваш веб-сайт использует федеративный поставщик удостоверений. Поскольку у каждого поставщика федеративных удостоверений будет своя собственная реализация, лучшим решением будет проверить документацию вашего поставщика или обратиться к нему за дальнейшими рекомендациями.
Если вы используете устаревшую библиотеку платформы JavaScript для входа в Google , вы можете найти информацию о том, как перейти на более новую библиотеку Google Identity Services для аутентификации и авторизации.
Большинство сайтов, использующих новую библиотеку Google Identity Services, готовы к прекращению поддержки сторонних файлов cookie, поскольку библиотека автоматически перейдет на использование FedCM для совместимости. Мы рекомендуем протестировать ваш сайт с включенным флагом тестирования сторонних файлов cookie и, при необходимости, использовать для подготовки контрольный список миграции FedCM .
Отдельный домен для входа
Некоторые веб-сайты используют другой домен только для аутентификации пользователей, которые не соответствуют критериям использования файлов cookie того же сайта, например веб-сайт, использующий example.com для основного сайта и login.example для процесса входа в систему, для чего может потребоваться доступ к сторонним файлам cookie. убедитесь, что пользователь аутентифицирован в обоих доменах.
Возможные пути миграции для этого сценария:
- Обновление для использования основных файлов cookie («того же сайта») . Изменение инфраструктуры веб-сайта таким образом, чтобы поток входа в систему размещался в том же домене (или поддомене), что и основной сайт, который будет использовать только основные файлы cookie. Это может потребовать больше усилий, в зависимости от того, как настроена инфраструктура.
- Используйте наборы связанных веб-сайтов (RWS): наборы связанных веб-сайтов обеспечивают ограниченный доступ к межсайтовым файлам cookie между небольшой группой связанных доменов. RWS — это API-интерфейс Privacy Sandbox, созданный для поддержки этого варианта использования. Однако RWS поддерживает доступ к межсайтовым файлам cookie только в ограниченном количестве доменов.
- Если вы выполняете аутентификацию пользователей в более чем 5 связанных доменах, изучите FedCM : Федеративное управление учетными данными (FedCM) позволяет поставщикам удостоверений полагаться на Chrome для обработки потоков, связанных с идентификацией, без необходимости использования сторонних файлов cookie. В вашем случае ваш «домен входа» может выступать в качестве поставщика удостоверений FedCM и использоваться для аутентификации пользователей в других ваших доменах.
Несколько доменов
Если у компании есть несколько продуктов, размещенных в разных доменах или поддоменах, она может захотеть разделить сеанс пользователя между этими продуктами, и этот сценарий может потребовать доступа к сторонним файлам cookie между несколькими доменами.
В этом случае размещение всех продуктов в одном домене зачастую нецелесообразно. Возможные решения в этом случае:
- Используйте наборы связанных веб-сайтов : когда необходим межсайтовый доступ к файлам cookie между небольшой группой связанных доменов.
- Используйте управление учетными данными федерации (FedCM) . Если количество доменов велико, вы можете использовать отдельный домен для входа в систему, который будет выступать в качестве поставщика удостоверений и аутентифицировать пользователей на ваших сайтах с помощью FedCM.
Решения для входа в систему
Сторонняя система единого входа (SSO)
Из-за сложности реализации решения единого входа многие компании предпочитают использовать стороннего поставщика решений, чтобы распределять состояние входа между несколькими источниками. Примеры поставщиков: Okta, Ping Identity, Google Cloud IAM или Microsoft Entra ID.
При использовании стороннего поставщика лучше всего обратиться к поставщику за рекомендациями о том, как изменения сторонних файлов cookie повлияют на решение и какой подход они рекомендуют для своего сервиса.
Решения единого входа с открытым исходным кодом
Многие компании, поддерживающие свои собственные решения единого входа, будут делать это с использованием установленных отраслевых стандартов, таких как OpenID Connect, OAuth или SAML, или существующих проектов с открытым исходным кодом, таких как Keycloak, WSO2, Auth.js или Hydra.
Мы рекомендуем проверить документацию вашего провайдера, чтобы понять, как изменения файлов cookie могут повлиять на их решение, а также лучший путь миграции для этого конкретного решения.
Индивидуальные внутренние решения
Если ваше решение для входа в систему попадает в один из предыдущих вариантов использования и создано собственными силами, в разделе «Подготовка к поэтапному отказу от сторонних файлов cookie» более подробно объясняется, как проверять ваш код и готовиться к изменениям сторонних файлов cookie.
Примите меры сейчас!
Если ваш веб-сайт подпадает под один из вариантов использования, существует несколько решений для устранения любого возможного воздействия: от перемещения потока аутентификации в основной домен, чтобы он использовал только собственные файлы cookie, до использования наборов связанных веб-сайтов , чтобы разрешить обмен файлами cookie между небольшое количество доменов или использование управления учетными данными Федерации .
Настал момент провести аудит вашего сервиса и подготовиться к изменениям сторонних файлов cookie!