Реализация единого входа из собственных приложений в внедренные веб-представления

Применяется: зеленый круг с символом белой галочки, указывающим, что следующее содержимое применяется к внешним клиентам. Внешние клиенты (дополнительные сведения)

Когда мобильное приложение включает веб-функции, такие как страница обновления профиля или панель мониторинга вознаграждения, пользователи ожидают простого единого входа. Они не должны столкнуться со вторым запросом входа после того, как уже вошли через родное приложение.

В этой статье показано, как реализовать единый вход между родным мобильным приложением и веб-ресурсом, размещенным во встроенном веб-представлении (например, WKWebView в iOS или WebView в Android). В отличие от системных браузеров, внедренные веб-представления позволяют управлять сетевыми запросами до их отправки. Эта возможность позволяет приложению внедрять состояние проверки подлинности пользователя непосредственно в заголовки запросов.

Рекомендуемый поток работает следующим образом:

  1. Пользователь входит через родной пользовательский интерфейс мобильного приложения с помощью Native Auth SDK или родного API аутентификации.
  2. Перед загрузкой веб-представления приложение получает действительный маркер доступа из пакета SDK или API.
  3. Приложение загружает веб-интерфейс с пользовательским запросом, который включает токен доступа в заголовке Authorization: Bearer <access_token>.
  4. Веб-ресурс проверяет маркер и немедленно предоставляет доступ.

На следующей схеме показано взаимодействие между веб-ресурсом, мобильным приложением, пакетом SDK и службой удостоверений (ESTS):

Диаграмма последовательности, показывающая поток единого входа, в котором мобильное приложение осуществляет вход с помощью SDK, получает токены и загружает веб-вид с токеном доступа в заголовке Authorization.

Необходимые условия

Вход с помощью встроенной аутентификации

Выполните стандартный поток входа с помощью Native Auth SDK или родного API аутентификации. При успешном входе с помощью SDK он безопасно кэширует токен доступа, ID токен и токен обновления. Если вы используете API напрямую, ваше приложение отвечает за безопасное хранение маркеров, которые он получает.

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

Получение токена доступа

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

Если вы используете Native Auth SDK, запросите токен в фоновом режиме. Пакет SDK предоставляет метод, который получает действительный getAccessToken() маркер из кэша или автоматически обновляет его. Дополнительные сведения о получении маркеров доступа с определенными областями см. в статье:

Если вы используете собственный API аутентификации непосредственно, ваше приложение получает токены через конечную точку API /oauth/v2.0/token. Для получения дополнительных сведений см. справочник по API нативной аутентификации.

Запросите токен с точными правами доступа, необходимыми для веб-ресурса. Требования к области см. в разделе "Ограничения" и требования к конфигурации.

Загрузка веб-просмотра с проверкой подлинности

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

Вставьте маркер доступа непосредственно в Authorization заголовок исходного HTTP-запроса, используемого для загрузки веб-представления. Это самый безопасный и надежный метод.

Этот подход предпочтителен, так как он:

  • Не сохраняет состояние: он не зависит от постоянных файлов cookie на стороне клиента.
  • Изолирует маркер: он строго ограничивает маркер этим конкретным потоком запросов.
  • Избегает векторов атак на основе веб-сайтов. Это позволяет обойти распространенные проблемы безопасности, связанные с сеансами, управляемыми браузером.

Чтобы загрузить веб-представление с проверкой подлинности на основе заголовков, выполняйте следующие действия.

  1. Создайте URL-адрес для веб-ресурса. Убедитесь, что он использует ПРОТОКОЛ HTTPS.
  2. Создайте объект пользовательского сетевого запроса.
  3. Добавьте заголовок Authorization: Bearer <access_token> в запрос.
  4. Загрузите запрос в компонент веб-представления (например, WKWebView в iOS или WebView Android).

Вариант B. Использование файлов cookie (только для резервного использования)

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

Внедрение файлов cookie в веб-представление доверяет состояние проверки подлинности механизму, управляемому браузером. Это делает сеанс "ambient" (автоматически присоединённым к запросам), что подвергает приложение стандартным классам веб-атак:

  • XSS (межсайтовый скрипт) — сеанс уязвим для перехвата, если веб-содержимое скомпрометировано.
  • CSRF (подделка запросов между сайтами): существует риск непреднамеренных подтвержденных запросов.
  • Фиксация сеанса. Злоумышленник может управлять состоянием сеанса.
  • Соответствие требованиям. Этот подход конфликтует с рекомендациями по обеспечению безопасности (например, MASTG-KNOW-0018) относительно сохранения конфиденциального состояния в jar-файлах cookie веб-представления.

Предупреждение

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

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

  • Используйте файлы cookie сеанса, выдаваемые сервером, когда это возможно.
  • Избегайте размещения необработанных маркеров доступа непосредственно в файлы cookie.
  • Установите файлы cookie, используя HttpOnly, Secure и соответствующие SameSite атрибуты.
  • Применение строгой защиты CSRF на стороне сервера.

Проверка подлинности и сохранение токена на стороне сервера

Когда запрос достигает веб-ресурса, сервер обрабатывает токен для установления сеанса.

Проверка токена

Веб-сервер перехватывает входящие запросы и проверяет подпись и утверждения токена. Для серверной части ASP.NET Core используйте Microsoft.Identity.Web (MISE) для автоматической обработки проверки.

Убедитесь, что утверждение аудитории (aud) токена совпадает с идентификатором веб-API, а утверждение издателя (iss) соответствует ожидаемому доверенному участнику.

Сохранение сеанса

Веб-представление не сохраняет пользовательские заголовки при последующих событиях навигации (например, когда пользователь выбирает ссылку). Чтобы сохранить состояние аутентификации после первоначального запроса, сервер выдает стандартный файл cookie сеанса (Set-Cookie) после успешной проверки изначального токена носителя.

Настройте файл cookie сеанса со следующими атрибутами:

  • HttpOnly
  • Secure
  • Соответствующая SameSite политика

Ограничения и требования к конфигурации

Чтобы убедиться, что маркер, выданный мобильному приложению, принимается веб-ресурсом, имейте в виду следующие конфигурации:

  • Общее удостоверение клиента: мобильное приложение и веб-приложение должны совместно использовать один и тот же идентификатор клиента (идентификатор приложения). Если у них разные идентификаторы, бэкенд отклоняет токен мобильного приложения, поскольку аудитория не совпадает.
  • Выравнивание областей доступа: Мобильное приложение запрашивает токен доступа с точными правами доступа, необходимыми для веб-ресурса (например, Profile.Read, Orders.Write).

Note

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

Связанный контент

  • Last updated on