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

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

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

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

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

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

Обзор решения

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

Для платформа удостоверений Майкрософт spAs и собственных клиентов следуйте аналогичным рекомендациям по протоколу:

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

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

• Универсальный код ресурса (URI) перенаправления должен быть помечен как тип spa , чтобы включить CORS в конечных точках входа.
• Маркеры обновления, выданные через поток кода авторизации для spa перенаправления URI, имеют 24-часовое время существования, а не 90-дневное время существования.

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

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

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

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

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

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

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

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

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

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

Вы можете достичь единого входа между iframed и родительскими приложениями с доступом к API скриптов JavaScript с одинаковым источником и кросс-источником, передав указание пользователя (учетной записи) из родительского приложения в приложение iframed. Дополнительные сведения см. в статье "Использование MSAL.js в приложениях iframed в репозитории 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 см. в следующей статье:

• Поток кода авторизации.
• краткое руководство по MSAL.js 2.0.