Ключи доступа в нативных приложениях: нативная реализация vs. реализация через WebView

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

Our mission is to make the Internet a safer place, and the new login standard passkeys provides a superior solution to achieve that. That's why we want to help you understand passkeys and its characteristics better.

1. Варианты реализации ключей доступа в нативных приложениях#

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

1.1 Нативная реализация: отличный UX#

Нативная реализация часто рассматривается как обеспечивающая лучший пользовательский опыт в приложении. Она характеризуется плавным, интегрированным и целостным взаимодействием с пользователем, точно адаптированным к среде операционной системы, будь то iOS или Android. Требованием для 100% нативной реализации является полный отказ от паролей и переход на использование исключительно ключей доступа. Этот подход избавляет вас от возможных трудностей при переходе между нативным приложением и веб-контентом (отображаемым через WebView).

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

1.2 Реализация через WebView: опыт, подобный браузерному#

При разработке нативного приложения путь к полностью нативной реализации не всегда возможен. В сценариях, где все еще необходимо поддерживать аутентификацию на основе паролей с использованием OAuth2, полная нативная интеграция может быть нецелесообразной, что делает реализацию через WebView единственной жизнеспособной альтернативой. WebView действует как мост, встраивая веб-контент непосредственно в ваше приложение и обеспечивая пользовательский опыт, подобный браузерному, при навигации по веб-страницам. Это особенно актуально, если вы сами являетесь провайдером OAuth2, ваше базовое решение для аутентификации основано на OAuth2 или если ваше решение для входа использует социальные входы через сторонние сервисы, такие как Google или GitHub. В этих случаях использование WebView становится неизбежным из-за необходимости взаимодействия с веб-контентом и управления различными потоками аутентификации пользователей, особенно когда требуются ассоциации с нативными приложениями.

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

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

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

Более 10 000 разработчиков доверяют Corbado и делают Интернет безопаснее с помощью ключей доступа. Есть вопросы? Мы написали более 150 статей о ключах доступа.

Присоединяйтесь к сообществу Passkeys

2. Обзор вариантов WebView#

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

2.1 WebView в iOS#

WKWebView
SFSafariViewController
SFAuthenticationSession / ASWebAuthenticationSession (специально разработанные для потоков аутентификации на основе OAuth / OpenID Connect)

2.1 WebView в Android#

WebView
Chrome Custom Tabs (CCT)

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

Subscribe to our Passkeys Substack for the latest news.

3. WebView в iOS#

WebView в iOS — это либо WKWebView, либо SFSafariViewController (при работе с OAuth / OIDC это SFAuthenticationSession / ASWebAuthenticationSession).

Для тестирования различного поведения WebView в iOS мы рекомендуем приложение WebView - WKWebView and UIWebView rendering.

3.1 WKWebView#

WKWebView — это мощный и универсальный вариант WebView, доступный для разработчиков iOS. Представленный в iOS 8, он позволяет разработчикам встраивать веб-контент непосредственно в приложение, предоставляя широкий спектр опций для кастомизации и конфигурации. WKWebView известен своей производительностью, так как использует тот же движок рендеринга, что и Safari, и предлагает богатый набор API для взаимодействия с веб-контентом, управления навигацией, пользовательскими взаимодействиями и многим другим.

3.2 SFSafariViewController#

SFSafariViewController — это WebView, который позволяет разработчикам использовать возможности Safari непосредственно в своих приложениях. Он обеспечивает бесшовный пользовательский опыт, используя настройки Safari пользователя, такие как сохраненные пароли, ключи доступа, файлы cookie и многое другое, обеспечивая последовательный веб-браузинг, поскольку он фактически работает как приложение Safari. SFSafariViewController не так настраиваем, как WKWebView, но предлагает улучшенные функции безопасности и простоту использования, что делает его предпочтительным выбором для отображения простого веб-контента в приложениях.

	WKWebView	SFSafariViewController
Пользовательский опыт	- Ощущение нативности: Пользователи могут чувствовать, что веб-контент является нативной частью приложения, поскольку разработчики могут настраивать внешний вид, чтобы он соответствовал дизайну приложения. - Автозаполнение: Возможно автозаполнение данных из Safari.	- Бесшовность: Бесшовный пользовательский опыт с использованием настроек Safari пользователя, обеспечивающий последовательный веб-браузинг между нативным приложением и браузером.
Опыт разработчика	- Высокая настраиваемость: Доступна обширная кастомизация и конфигурация. - Гибкость: Множество API для взаимодействия с веб-контентом.	- Средняя настраиваемость: Ограниченные возможности кастомизации, особенно по сравнению с WKWebView. - Простота: Проще в реализации по сравнению с WKWebView.
Производительность	- Довольно медленная: В зависимости от реализации и веб-контента скорость загрузки можно оптимизировать, но она все равно может быть ниже по сравнению с SFSafariViewController из-за дополнительной обработки пользовательских функций и взаимодействий.	- Довольно быстрая: Обычно предлагает лучшую производительность, так как использует движок Safari, оптимизированный для скорости и эффективности, обеспечивая быструю загрузку веб-страниц.
Доверие и узнаваемость	- Отображение URL не требуется: WKWebView часто не показывает URL, что затрудняет пользователям проверку веб-страницы. Потенциально вредоносные приложения могут имитировать это поведение для фишинга учетных данных.	- Опыт, подобный браузерному: Рендерит веб-страницы с помощью Safari, обеспечивая «браузерный» опыт. Пользователи могут видеть URL и получать доступ к функциям автозаполнения Safari, что потенциально внушает больше доверия благодаря знакомому интерфейсу.
Изоляция	- Разделены: Файлы cookie и сессии отделены от Safari; пользователи не будут автоматически входить в систему в WKWebView.	- Разделены: Файлы cookie и сессии также отделены от Safari; пользователи не будут автоматически входить в систему в SFSafariViewController.
Уязвимости	- Безопасный: По своей сути безопасен благодаря песочнице приложений Apple, но поведение и безопасность зависят от реализации приложения. Возможны уязвимости при неправильной реализации.	- Более безопасный: Выигрывает от встроенных функций безопасности Safari, включая защиту от фишинга и предупреждения о вредоносных сайтах. В целом считается более безопасным для отображения веб-контента, чем WKWebView, благодаря этим функциям и знакомству пользователей с Safari.
Прочее	- Функции недоступны: Некоторые функции браузера (например, WebAuthn) могут быть не полностью доступны из-за соображений безопасности и того, что WKWebView работает в контексте приложения. - Внедрение JavaScript: Некоторые приложения, например, TikTok, внедряют отслеживающий JavaScript в свой встроенный WKWebView или ограничивают контроль пользователя (например, Facebook). - Проблемы с конфиденциальностью: Больше отзывов сообщества относительно конфиденциальности.	- Нет внедрения JavaScript: Не позволяет выполнять JavaScript из приложения, что повышает безопасность и конфиденциальность. Также не поддерживает JavaScript-оповещения или подтверждения, что потенциально может повлиять на пользовательский опыт на некоторых веб-страницах. - Режим чтения: Предоставляет режим чтения для чистого, удобного для чтения варианта статей.

3.3 SFAuthenticationSession / ASWebAuthenticationSession#

SFAuthenticationSession и ASWebAuthenticationSession — это WebView, специально разработанные для потоков аутентификации на основе OAuth / OpenID Connect. Они предоставляют безопасное и изолированное пространство для аутентификации пользователей, защищая их учетные данные и гарантируя, что личная информация не будет случайно передана приложению. Эти сессии обмениваются файлами cookie и данными веб-сайтов с Safari, обеспечивая последовательный и бесшовный пользовательский опыт, особенно во время процессов аутентификации.

Плюсы:

Специализированная аутентификация: Специально разработаны для потоков аутентификации на основе OAuth / OpenID Connect, обеспечивая оптимизированный процесс аутентификации.
Защита конфиденциальности: Обеспечивает конфиденциальность данных пользователя, не передавая файлы cookie или данные веб-сайтов приложению.
Поддержка SSO: Поддерживает единый вход (Single Sign-On), обеспечивая удобный пользовательский опыт.

Минусы:

Ограниченный сценарий использования: В основном ориентирован на аутентификацию OAuth / OpenID Connect, что может не подходить для всех сценариев использования.

Когда основной задачей является аутентификация пользователя, особенно при реализации SSO или взаимодействии с провайдерами OAuth, следует использовать SFAuthenticationSession / ASWebAuthenticationSession вместо SFSafariViewController.

Want to find out how many people use passkeys?

View Adoption Data

4. WebView в Android#

WebView в Android — это либо WebView, либо Chrome Custom Tabs (CCT). Для тестирования различного поведения WebView в Android мы рекомендуем приложение WebView vs Chrome Custom Tabs.

4.1 Android WebView#

WebView на Android — это комплексный компонент, который позволяет разработчикам отображать веб-контент как часть пользовательского интерфейса приложения. Он универсален, предлагает широкий спектр опций кастомизации и предоставляет разработчикам гибкость для настройки WebView в соответствии с различными потребностями. WebView предоставляет богатый набор API для взаимодействия с веб-контентом, управления пользовательскими взаимодействиями и даже обработки диалоговых окон JavaScript, клиентских сертификатов и запросов разрешений.

4.2 Chrome Custom Tabs (CCT)#

Chrome Custom Tabs (CCT) предлагает бесшовный, безопасный и эффективный способ интеграции веб-контента непосредственно в ваше приложение. Используя возможности и функции безопасности Chrome, CCT обеспечивает пользовательский опыт, который является одновременно последовательным и высокопроизводительным.

CCT — это компонент браузера Chrome, разработанный для интеграции с фреймворком Android, позволяющий приложениям открывать веб-контент в легковесном, выделенном процессе. Примечательно, что он открывается быстрее, чем обычный браузер, и при предварительной загрузке через вызов warm-up потенциально превосходит WebView по производительности. Хотя он выполняет JavaScript, он работает в своем собственном процессе, защищая приложения от выполнения вредоносного кода. Более того, пользовательский интерфейс CCT предоставляет панель действий, отображающую URL и значок замка для проверки SSL на защищенных страницах, тем самым убеждая пользователей в подлинности и безопасности загружаемой страницы.

В целом, можно сказать, что iOS WKWebView и Android WebView, а также SFSafariViewController и Chrome Custom Tabs (CCT) схожи.

Функция	WebView	Chrome Custom Tab
Пользовательский опыт	- Гибкость: Предоставляет богатый набор API для взаимодействия с веб-контентом и управления пользовательскими взаимодействиями, включая обработку диалоговых окон JavaScript и запросов разрешений. - Согласованность: Управление согласованным UX, особенно с разнообразным веб-контентом, может быть сложной задачей.	- Функции браузера: Использует такие функции, как экономия трафика (Data Saver) и синхронизированное автозаполнение на разных устройствах. - Кнопка «Назад»: Позволяет пользователям легко вернуться в приложение с помощью встроенной кнопки «Назад». - Зависимость: Зависит от приложения Chrome, которое может быть недоступно или не обновлено на всех устройствах пользователя. - Перенаправление в браузер: Некоторые функции могут перенаправлять пользователей в приложение Chrome, что потенциально нарушает пользовательский опыт. - Частичные кастомные вкладки: Только часть экрана может быть использована для Chrome Custom Tab, в то время как на остальной части отображается нативное приложение. - Боковая панель: В ландшафтном режиме и на устройствах с большим экраном Chrome Custom Tab отображается только с одной стороны экрана, в то время как на остальной части экрана отображается нативное приложение.
Опыт разработчика	- Высокая настраиваемость: Предлагает широкие возможности/потребности в кастомизации. - Интерактивность: Предоставляет многочисленные API для взаимодействия с веб-контентом и управления пользовательскими взаимодействиями.	- Настраиваемость: Позволяет настраивать цвет панели инструментов, кнопку действия, нижнюю панель инструментов, пользовательские пункты меню и анимации входа/выхода. - Коллбэк: Отправляет коллбэк в приложение при внешней навигации. - Функции безопасности: Предоставляет готовые функции, избавляя от необходимости управлять запросами, предоставлением разрешений или хранилищами cookie.
Производительность	- Посредственная производительность: Может не предлагать тот же уровень производительности, что и Chrome Custom Tabs (CCT).	- Предварительный «прогрев»: Включает предварительный «прогрев» браузера в фоновом режиме и спекулятивную загрузку URL-адресов для ускорения загрузки страниц. - Приоритет: Предотвращает выгрузку приложений, запускающих Custom Tab, во время его использования, повышая его важность до уровня «переднего плана».
Доверие и узнаваемость	- URL и SSL не видны: URL и информация SSL по своей сути не видны в WebView. Если разработчик приложения не реализует эти функции, пользователи не будут знать, находятся ли они на правильном веб-сайте или на фишинговом.	- URL и SSL видны: Использует фактический браузер Chrome для рендеринга страниц. Пользователи могут видеть URL и SSL-сертификат (указывающий, является ли соединение безопасным). Это может дать пользователям уверенность в том, что они не на фишинговом сайте.
Изоляция	- Работает в процессе приложения: Если в приложении есть уязвимость, позволяющая выполнять вредоносный код, существует риск компрометации WebView. Однако WebView также получает обновления, но его поведение и безопасность могут больше зависеть от использующего его приложения. - Нет общего доступа к cookie/сессиям: Не делится файлами cookie или сессиями с основным браузером устройства, обеспечивая изоляцию, но, возможно, требуя от пользователей повторного входа.	- Работает в процессе Chrome: Являясь частью Chrome, Custom Tabs работают в том же процессе и имеют те же обновления безопасности и функции, что и Chrome. - Общее хранилище cookie и модель разрешений: Гарантирует, что пользователям не придется повторно входить на сайты или заново предоставлять разрешения. - Настройки и предпочтения Chrome: Использует настройки и предпочтения Chrome.
Уязвимости	- Коллбэки для кражи учетных данных: Потенциальные уязвимости включают то, что иногда требуется JavaScript, что открывает дверь для других приложений для выполнения вредоносного кода, такого как регистрация коллбэков, которые пытаются перехватить имена пользователей и пароли. - Фишинг: Кроме того, вредоносное приложение может открыть другую веб-страницу, которая имитирует поток Link в попытке фишинга.	- Google Safe Browsing: Использует Google Safe Browsing для защиты как пользователя, так и устройства от опасных сайтов. - Безопасное оформление браузера: Гарантирует, что пользователь всегда видит точный URL, с которым он взаимодействует, и может просматривать информацию о сертификате веб-сайта, что снижает риск фишинга. Кроме того, кастомные вкладки не допускают внедрения JavaScript.
Прочее	- Google запретил использование WebView для входа пользователей в аккаунты Google.

5. Рекомендации по реализации ключей доступа в нативных приложениях#

Наши клиенты постоянно спрашивают нас, как следует реализовывать ключи доступа в нативных приложениях. В основном этих клиентов можно разделить на разные группы:

Группа А:

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

Группа Б:

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

Добавить ключи доступа в существующий поток аутентификации через WebView (так это реализовали Google и GitHub в своих нативных приложениях).
Добавить ключи доступа через нативную реализацию поверх существующей. Эта нативная реализация ключей доступа проверяет перед старым WebView (например, для социальных входов и паролей), может ли пользователь войти с помощью ключа доступа (так это реализовала KAYAK в своем нативном приложении).

Определите свою группу

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

Рекомендация для группы А: Нативная реализация

Если вы создаете совершенно новое приложение (группа А), мы рекомендуем выбрать нативную реализацию ключей доступа и сразу полностью отказаться от паролей (то есть не использовать никакой WebView). Пожалуйста, используйте нативные SDK и API для iOS и Android (например, через пакет passkeys для Flutter). Также прочтите эту статью о Relying Party ID.

Рекомендация для группы Б: Сначала WebView, затем нативная реализация

Если вы по какой-либо причине не можете реализовать ключи доступа нативно сегодня (группа Б), вы можете начать с реализации через WebView, а затем в будущем перейти к нативной реализации ключей доступа (это работает через создание файлов ассоциации, таких как apple-app-site-association для приложений iOS и assetlinks.json для приложений Android). Причины для выбора реализации через WebView могут включать:

Вы уже предлагаете аутентификацию на основе OAuth2 и хотите продолжать предлагать ее своим пользователям (OAuth2 не работает нативно, см. стандарт здесь).
Вы хотите предлагать аутентификацию с помощью ключей доступа в том же окне/экране, где вы предлагаете другие методы аутентификации (например, пароли, социальные входы, OAuth2).

Именно так Google или GitHub в настоящее время реализовали аутентификацию с помощью ключей доступа в своих нативных приложениях. Пожалуйста, ознакомьтесь с приведенными ниже рекомендациями по правильной настройке WebView для аутентификации с помощью ключей доступа. Однако мы рекомендуем рассмотреть нативную реализацию ключей доступа, как это сделала KAYAK, и начать сразу со второго шага.

Если вы относитесь к группе Б и не можете реализовать ключи доступа нативно, наша рекомендация склоняется к использованию SFAuthenticationSession / ASWebAuthenticationSession для iOS и Chrome Custom Tabs для Android (иначе ключи доступа все равно не будут работать).

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

Далее мы приводим причины этой рекомендации:

SFAuthenticationSession / ASWebAuthenticationSession обмениваются файлами cookie и данными веб-сайтов с Safari, обеспечивая бесшовный пользовательский опыт во время процессов аутентификации. То же самое относится и к Chrome Custom Tabs на Android.

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

5.2 Повышенная безопасность#

SFAuthenticationSession / ASWebAuthenticationSession на iOS и Chrome Custom Tabs на Android предоставляют безопасное и изолированное пространство для аутентификации пользователей, гарантируя, что конфиденциальные учетные данные пользователей защищены и не передаются случайно приложению или другим веб-сайтам.

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

Более того, этот выбор дизайна выигрывает от постоянных обновлений и улучшений безопасности Safari и Chrome, гарантируя соответствие последним стандартам и протоколам безопасности.

5.3 Пользовательский опыт#

SFAuthenticationSession / ASWebAuthenticationSession на iOS и Chrome Custom Tabs на Android предоставляют последовательный и знакомый пользовательский интерфейс, поскольку пользователи привыкли к опыту использования браузера. Кроме того, применяются пользовательские настройки и предпочтения Safari и Chrome.

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

5.4 Производительность#

Chrome Custom Tabs используют производительность Chrome, обеспечивая плавный и отзывчивый пользовательский опыт, что особенно важно во время процессов аутентификации для предотвращения разочарования или отказа пользователей.

Производительность CCT часто превосходит варианты Android WebView (то же самое с SFAuthenticationSession / ASWebAuthenticationSession на iOS), обеспечивая быструю и плавную обработку веб-контента и потоков аутентификации.

Смотрите также это сравнение от Google, чтобы почувствовать разницу в производительности между Chrome Custom Tabs, Android WebView и стандартным браузером Chrome.

5.5 Специально для потоков аутентификации#

SFAuthenticationSession / ASWebAuthenticationSession специально разработан для обработки потоков аутентификации на основе OAuth / OpenID Connect, обеспечивая оптимизированный и безопасный процесс для этих широко используемых протоколов аутентификации. Это также рекомендуемый способ для аутентификации WebAuthn / с помощью ключей доступа.

На Android нет специального класса для потоков аутентификации, но аналогичное поведение можно реализовать с помощью Chrome Custom Tabs и Android App Links.

Кроме того, мы ожидаем, что все больше приложений будут внедрять ключи доступа, как TikTok, просто собирая их, когда пользователь аутентифицирован. Это можно сделать нативно (реализация TikTok) или через реализацию WebView. Подходящим подходом является нативный запуск Conditional UI. Если это не работает, вы отображаете реализацию WebView.

6. Заключение#

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