Как обрабатывать блокировку сторонних файлов cookie в браузерах

  • Статья

Многие браузеры блокируют сторонние файлы cookie, то есть файлы cookie для запросов к любым доменам, кроме указанного в адресной строке браузера. Эти файлы cookie также называются файлами cookie между доменами. Такая блокировка прерывает неявный поток и требует применять новые шаблоны проверки подлинности для успешного входа пользователей. На платформе удостоверений Майкрософт мы используем поток авторизации с ключом проверки для обмена кодом (PKCE) и маркерами обновления для сохранения пользователей в системе после входа в случае, когда сторонние файлы cookie блокируются.

Что такое интеллектуальная защита отслеживания (ITP) и песочница конфиденциальности?

В Apple Safari есть функция защиты конфиденциальности по умолчанию, которая называется интеллектуальной защитой от слежения или ITP. Chrome имеет инициативу конфиденциальности браузера с именем Песочница конфиденциальности. Эти инициативы охватывают множество различных усилий по конфиденциальности браузера браузеров и имеют разные временная шкала. Оба усилия блокируют файлы cookie сторонних производителей по запросам, которые пересекают домены, с Safari и Brave блокируют сторонние файлы cookie по умолчанию. Chrome недавно объявил, что они начнут блокировать сторонние файлы cookie по умолчанию. Песочница конфиденциальности включает изменения в секционированного хранилища , а также блокировку сторонних файлов cookie.

Общая форма отслеживания пользователей выполняется путем загрузки iFrame на сторонний сайт в фоновом режиме и использования файлов cookie для сопоставления пользователя через Интернет. К сожалению, этот шаблон также является стандартным способом реализации неявных потоков в одностраничных приложениях. Браузер, который блокирует сторонние файлы cookie для защиты конфиденциальности пользователей, также может блокировать функциональные возможности SPA.

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

Общие сведения о решении

Чтобы продолжить проверку подлинности пользователей в одностраничных приложениях, их разработчики должны использовать поток кода авторизации. В потоке кода авторизации поставщик удостоверений выдает код, а SPA активирует его для маркера доступа и маркера обновления. Если приложению требуются новые маркеры, он может использовать поток маркеров обновления для получения новых маркеров. Библиотека проверки подлинности Майкрософт (MSAL) для JavaScript версии 2.0 и более поздних версий реализует поток кода авторизации для spAs, а при дополнительных обновлениях — это замена для MSAL.js 1.x. См. руководство по миграции для перемещения SPA из неявного в поток кода проверки подлинности.

Для платформы удостоверений Майкрософт одностраничные приложения и собственные клиенты используют аналогичные правила протокола:

  • Используется запрос кода PKCE
    • PKCE является обязательным для одностраничных приложений на платформе удостоверений Майкрософт. PKCE рекомендуется для собственных и конфиденциальных клиентов.
  • Секрет клиента не используется

SpAs имеют два дополнительных ограничения:

Diagram showing the OAuth 2 authorization code flow between a single-page app and the security token service endpoint.

Влияние производительности и пользовательского интерфейса

Некоторые приложения, использующие неявный поток, предпринимают попытку выполнить вход без перенаправления, открывая iFrame для входа с помощью prompt=none. В большинстве браузеров этот запрос отвечает маркерами для текущего пользователя, вошедшего в систему (при условии предоставления согласия). В этом шаблоне приложениям не требовалось полностраничное перенаправление для входа пользователя в систему, что повышало производительность и удобство работы пользователя, так как при посещении веб-страницы он уже выполнял вход. Так как prompt=none в iframe больше нет возможности при блокировке сторонних файлов cookie, приложения должны настроить свои шаблоны входа, чтобы код авторизации был выдан.

Без сторонних файлов cookie существует два способа выполнения входа.

  • Полностраничные перенаправления
    • При первой загрузке SPA перенаправьте пользователя на страницу входа, если сеанс еще не существует (или истек срок его действия). Браузер пользователя посещает страницу входа, представляет файлы cookie, содержащие сеанс пользователя, а затем перенаправляется обратно в приложение с кодом и маркерами в фрагменте.
    • В результате перенаправления SPA загружается дважды. Чтобы избежать этого, выполните рекомендации по кэшированию одностраничных приложений.
    • Рассмотрите возможность последовательности предварительной загрузки в приложении, которая проверяет наличие сеанса входа и перенаправляет на страницу входа, прежде чем приложение полностью распакует и выполнит полезные данные JavaScript.
  • Всплывающие окна
    • Если взаимодействие с пользователем (UX) при полностраничном перенаправлении не работает для приложения, рассмотрите возможность использования всплывающего окна для обработки аутентификации.
    • Когда всплывающее окно завершит перенаправление в приложение после проверки подлинности, код в обработчике перенаправления будет хранить код проверки подлинности и маркеры в локальном хранилище для используемого приложения. MSAL.js поддерживает всплывающие окна для проверки подлинности, как и большинство библиотек.
    • Браузеры снижают поддержку всплывающих окон, поэтому они могут быть не самым надежным вариантом. Взаимодействие пользователя с SPA перед созданием всплывающего окна может потребоваться для удовлетворения требований браузера.

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

Мы используем всплывающее окно в качестве первой части перехода к странице входа, чтобы найти сеанс и указать код авторизации. Это должно работать и в будущем.

Разработчики могут продолжать использовать prompt=none с ожиданием, что они видят более высокую скорость interacion_required ошибок при блокировке сторонних файлов cookie. Рекомендация заключается в том, чтобы всегда иметь резервный вариант интерактивного метода, если возникают сбои во время автоматического приобретения маркера.

Использование IFRAME

Распространенный шаблон в веб-приложениях — использовать iframe для внедрения одного приложения в другое: кадр верхнего уровня обрабатывает проверку подлинности пользователя и приложение, размещенное в iframe, может доверять тому, что пользователь вошел в систему, автоматически извлекая маркеры с помощью неявного потока. Однако есть несколько предостережений для этого предположения независимо от того, включены ли сторонние файлы cookie или заблокированы в браузере.

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

Вы можете настроить единый вход между приложением в IFRAME и приложением верхнего уровня, которые используют API-интерфейсы для скриптов JavaScript в одном или в разных доменах, передавая сведения о пользователе (учетной записи) из родительского приложения в приложение в IFRAME. Дополнительные сведения см. в документе Using MSAL.js in iframed apps (Использование MSAL.js в приложениях IFRAME), размещенном в репозитории MSAL.js на сайте GitHub.

Влияние маркеров обновления на безопасность в браузере

Используя атаки межсайтовых сценариев (XSS) или скомпрометированные пакеты JS, можно украсть маркер обновления и использовать его удаленно до истечения срока действия или отзыва. Разработчики приложений отвечают за снижение риска для сценариев между сайтами. Чтобы свести к минимуму риск украденных маркеров обновления, spAs выдают маркеры, допустимые только в течение 24 часов. Через 24 часа приложение должно получить новый код авторизации через фрейм верхнего уровня, открыв страницу входа.

Этот шаблон маркера обновления с ограниченным сроком действия был выбран в качестве компромисса между безопасностью и ухудшенным взаимодействием с пользователем. Без маркеров обновления или сторонних файлов cookie поток кода авторизации (как рекомендуется в черновике оптимальных методов безопасности OAuth) становится обременительным, если требуются новые или дополнительные маркеры. Полностраничное перенаправление или всплывающее окно требуется для получения каждого отдельного маркера каждый раз по истечении срока действия маркера (для маркеров платформы удостоверений Майкрософт обычно через каждый час).

Устранение рисков конкретного типа пользователя

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

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

Для сценариев приложений Azure AD B2C клиенты могут настроить личный домен входа для сопоставления домена приложения. Браузеры не блокируют сторонние файлы cookie в этом сценарии, так как файлы cookie остаются в том же домене (например, login.contoso.com для app.contoso.com).

Ограничения на выход front-Channel без сторонних файлов cookie

При входе пользователя из SPA MSAL.js рекомендуется использовать метод выхода всплывающего окна или перенаправления. Хотя это очищает сеанс проверки подлинности на сервере и в хранилище браузеров, существует риск того, что без доступа к сторонним файлам cookie не все федеративные приложения будут видеть выход одновременно. Это известное ограничение спецификации OpenID Front-Channel Logout 1.0. Это означает, что существующие маркеры доступа для других приложений для того же пользователя будут оставаться действительными до истечения срока действия. Пользователь может выйти из приложения A на вкладке A, но приложение B на вкладке B по-прежнему отображается как вошедший в систему для оставшегося допустимого времени маркера доступа. Когда срок действия маркера B приложения и вызов выполняется на сервере, чтобы получить новый маркер, приложение B получает ответ от сервера, срок действия сеанса и запрос на проверку подлинности пользователя.

Страница выхода Майкрософт и рекомендации по конфиденциальности интернета рекомендуют пользователям закрывать все окна браузера после выхода из приложения.

Следующие шаги

Дополнительные сведения о потоке кода авторизации и библиотеке MSAL.js см. в следующих статьях: