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

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

Ключевые факторы для принятия решения:

• Вход через OAuth? → Системный WebView (ASWebAuthenticationSession, Chrome Custom Tabs)
• Хотите повторно использовать веб-аутентификацию в нативной оболочке? → Встроенный WebView (WKWebView, Android WebView с WebKit 1.12.1+)
• Создаете нативное приложение с нуля? → Нативная реализация (Apple AuthenticationServices, Google Credential Manager)

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

1. Нативная реализация: Встройте процессы использования ключей доступа непосредственно в ваше приложение, используя API платформы (iOS AuthenticationServices, Android Credential Manager). Обеспечивает наилучший пользовательский опыт с бесшовной биометрической аутентификацией, но требует от средних до высоких технических усилий по реализации.

2. Системный WebView: Используйте браузерный компонент платформы (iOS ASWebAuthenticationSession / SFSafariViewController, Android Chrome Custom Tabs) для обработки аутентификации. Отлично подходит для процессов входа на основе OAuth и делится учетными данными с системным браузером.

3. Встроенный WebView: Встройте настраиваемый веб-просмотрщик (iOS WKWebView, Android WebView) в ваше приложение, чтобы повторно использовать веб-аутентификацию в нативном каркасе приложения. Обеспечивает внешний вид, близкий к нативному, без адресной строки и полный контроль над пользовательским интерфейсом веб-просмотра. Требует дополнительных настроек, включая разрешения и права (iOS), а также конфигурацию WebView с AndroidX WebKit 1.12.1+ (Android) для активации функциональности ключей доступа.

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

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

Когда выбирать нативную реализацию:

• Создание нового нативного приложения или рефакторинг аутентификации на нативные экраны
• Желание получить наилучший возможный пользовательский опыт с мгновенной, тихой аутентификацией
• Автоматические запросы ключей доступа при запуске приложения: Нативные реализации могут использовать preferImmediatelyAvailableCredentials для автоматического отображения оверлея ключей доступа при их наличии, обеспечивая максимально быстрый вход без необходимости ввода идентификатора
• Необходим полный контроль над интерфейсом и процессом аутентификации
• Готовность инвестировать в платформенно-специфичную реализацию (iOS Swift, Android Kotlin)

Ключевое преимущество: preferImmediatelyAvailableCredentials()

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

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

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

Обзор технических требований:

Интеграция нативных ключей доступа требует криптографического доверия между вашим приложением и веб-доменом. Без этого ОС отклонит все операции WebAuthn. Ключевые требования:

1. Файлы ассоциации приложения и домена, размещенные в /.well-known/
2. Правильный Relying Party ID, соответствующий вашему веб-домену
3. Возможности, специфичные для платформы (подробно описано в разделе 4)

Главное преимущество: ключи доступа, созданные на вашем сайте, без проблем работают в вашем приложении и наоборот.

Реализация ключей доступа нативным образом в iOS включает фреймворк Apple AuthenticationServices, который предоставляет API для операций WebAuthn:

Ключевые компоненты:

• ASAuthorizationController: Управляет процессом аутентификации
• ASAuthorizationPlatformPublicKeyCredentialProvider: Создает запросы ключей доступа
• Три различных режима UI для обработки входа по ключам доступа:
  • Вход через текстовое поле: Традиционное поле имени пользователя со входом по ключу доступа, начинающимся при нажатии кнопки отправки
  • Модальный оверлей ключей доступа: Диалог ОС, в котором перечислены доступные ключи доступа
  • Conditional UI: Предложения ключей доступа в панели QuickType над клавиатурой

Советы по разработке

• Кэширование AASA: Apple агрессивно кэширует файл AASA (до 24 часов), что может затруднить тестирование. Решение: Включите Developer Mode на тестовом устройстве и добавьте ?mode=developer к вашему URL-адресу AASA для принудительного получения свежих данных
• Тестирование производительности: Тестируйте с учетными записями iCloud, содержащими сотни учетных данных, чтобы наблюдать за задержкой в реальных условиях. Системный оверлей может показать небольшую задержку при наличии множества сохраненных ключей доступа

Нативная реализация ключей доступа в Android использует Credential Manager API (или старый FIDO2 API для обратной совместимости):

Ключевые компоненты:

• CredentialManager: Центральный API для всех операций с учетными данными
• CreatePublicKeyCredentialRequest: Для регистрации ключа доступа
• GetCredentialRequest: Для аутентификации по ключу доступа
• Два основных режима UI:
  • Вход через текстовое поле: Традиционное поле имени пользователя со входом по ключу доступа, начинающимся при нажатии кнопки отправки
  • Модальный оверлей ключей доступа: Диалог ОС, в котором перечислены доступные ключи доступа

Примечание: В настоящее время в нативных приложениях Android отсутствуют предложения Conditional UI над клавиатурой, как в iOS (хотя Conditional UI работает в веб-приложениях)

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

1. Например, наша команда столкнулась с такими проблемами, как агрессивное кэширование файла apple-app-site-association (используемого для связывания учетных данных приложения и веба) и незначительные различия в пользовательском интерфейсе некоторых биометрических подсказок OEM-производителей Android.
2. Кроме того, учитывайте, что в некоторых корпоративных сценариях синхронизация ключей доступа на управляемых устройствах может быть отключена политикой. В корпоративных средах, где синхронизация iCloud Keychain или Google Password Manager отключена, ключи доступа привязываются к устройству и не перемещаются — это важный сценарий, который необходимо планировать (например, убедиться, что пользователи все еще могут войти в систему, если они получат новый телефон).
3. Дополнительно, сторонние приложения менеджеров учетных данных могут влиять на процесс. Например, если у пользователя в качестве активного провайдера учетных данных установлен менеджер паролей, такой как 1Password, он часто перехватывает создание и хранение ключей доступа, имея приоритет над нативным менеджером учетных данных платформы.

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

Рекомендация: Для нативных реализаций мы рекомендуем использовать SDK Corbado (iOS Swift Passkey SDK, Android Kotlin Passkey SDK), которые обрабатывают многочисленные пограничные случаи, обнаруженные при развертывании в производственной среде, предоставляют дополнительную телеметрию и тестирование.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

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

Когда выбирать системный WebView:

• Ваше приложение использует вход на основе OAuth: Системный WebView — это рекомендуемый подход для процессов OAuth2/OIDC, обеспечивающий безопасную аутентификацию
• Существующая веб-аутентификация, которую вы хотите повторно использовать в мобильных приложениях
• Необходимость поддержки нескольких методов аутентификации (пароли, вход через соцсети, ключи доступа) без нативной переделки
• Желание поддерживать единую кодовую базу аутентификации в вебе и на мобильных устройствах

Ключевые преимущества:

• Совместимость с OAuth: Специально создан для процессов аутентификации OAuth/OIDC
• Индикаторы безопасности: Пользователи видят фактический URL и SSL-сертификаты, что укрепляет доверие
• Низкие усилия по реализации: Требуется минимальный нативный код
• Единообразный UX: Знакомый интерфейс браузера, которому пользователи уже доверяют

Компоненты платформы:

• iOS: ASWebAuthenticationSession (рекомендуется для процессов аутентификации) или SFSafariViewController (общий просмотр)
• Android: Chrome Custom Tabs (CCT)

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

iOS предоставляет два основных компонента системного WebView для аутентификации:

ASWebAuthenticationSession (Рекомендуется для аутентификации):

• Специально создан для OAuth/OIDC и безопасных процессов входа
• Автоматически предупреждает пользователя о том, что приложение хочет выполнить аутентификацию
• Делится файлами cookie и учетными данными с Safari
• Поддерживает ключи доступа через iCloud Keychain

SFSafariViewController (Общий просмотр):

• Полноценный опыт Safari внутри приложения
• Отображает адресную строку и индикаторы безопасности
• Не делится файлами cookie Safari в iOS 11+; используйте ASWebAuthenticationSession, когда требуется совместное использование сеанса Safari
• Менее настраиваемый, но более заслуживающий доверия пользователей

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

Chrome Custom Tabs (CCT) предоставляют возможности аутентификации на базе Chrome внутри вашего приложения:

Whitepaper по Passkey для Enterprise. Практические рекомендации, шаблоны внедрения и KPI для программ passkeys.

Получить whitepaper

Ключевые особенности:

• Делится файлами cookie и учетными данными с браузером Chrome
• Отображает URL и индикаторы безопасности
• Можно настроить цвет панели инструментов и брендинг
• Предварительный разогрев для ускорения загрузки

Интеграция с OAuth: Chrome Custom Tabs — это эквивалент ASWebAuthenticationSession для Android, обеспечивающий отличную поддержку OAuth при сохранении доступа к сохраненным ключам доступа.

Попробуйте passkeys в live demo.

Попробовать passkeys

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

Когда выбирать встроенный WebView:

• Опыт, близкий к нативному: Ваше приложение уже встраивает аутентификацию в настроенный веб-просмотр для поддержания внешнего вида и ощущения нативного приложения, и вы хотите сохранить этот единообразный пользовательский опыт
• Требуется контроль сессии/файлов cookie: Ваше приложение требует прямого управления токенами аутентификации и состоянием сессии после завершения аутентификации OAuth
• Существующий процесс аутентификации, где аутентификация через системный WebView возвращает код авторизации, но не сессию во встроенных контекстах
• Необходимо поддерживать состояние аутентификации на нескольких встроенных веб-экранах
• Только первичная аутентификация: Ваше приложение обрабатывает аутентификацию напрямую, сторонние реализации ключей доступа рассматриваются отдельно
• AndroidX WebKit 1.12.1+ с определением функций во время выполнения
• Допустимо ограничение Conditional UI для входа (не поддерживается во встроенном WebView), не актуально для настроек управления

Важный контекст:

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

Технические требования:

Встроенные WebView требуют дополнительных настроек по сравнению с системными WebView:

1. iOS: Права Associated Domains, конфигурация файла AASA
2. Android: AndroidX WebKit 1.12.1+ с конфигурацией WebView WebAuthn (требуется определение функций)
3. Оба: Должны быть правильно настроены известные файлы ассоциации и Digital Asset Links

Компоненты платформы:

• iOS: WKWebView
• Android: android.webkit.WebView

Компромиссы:

• Средняя сложность: Требует конфигурации WebView (Android WebKit 1.12.1+) и настройки прав (iOS)
• Более низкое принятие ключей доступа: Пользователи могут столкнуться с большими трудностями по сравнению с нативной реализацией
• Conditional UI не поддерживается: Автозаполнение ключей доступа в полях ввода не работает во встроенном WebView на Android
• Ограниченная поддержка платформы: Некоторые функции могут работать нестабильно (например, автоматическое создание ключей доступа)

При реализации ключей доступа через WebView крайне важно понимать разницу между системными WebView и встроенными WebView. Три подхода, описанные выше (Нативная реализация, Системный WebView и Встроенный WebView), служат для разных случаев использования.

На iOS у вас есть несколько вариантов отображения веб-контента внутри приложения:

• WKWebView — это настраиваемый WebView, который является частью фреймворка WebKit (появился в iOS 8). Он дает вам большой контроль над внешним видом и поведением веб-контента.
• SFSafariViewController — это контроллер представления, предоставленный Apple, который действует как облегченный браузер Safari в вашем приложении. Он использует движок Safari. На iOS 11+ он имеет отдельное хранилище cookie и не делится файлами cookie с Safari. Используйте ASWebAuthenticationSession, когда требуется совместное использование сеанса Safari.
• SFAuthenticationSession / ASWebAuthenticationSession — это специализированные сеансы веб-аутентификации (доступные с iOS 11/12), предназначенные специально для OAuth/OpenID или других процессов безопасного входа. Они также используют Safari "под капотом", но ориентированы на процессы аутентификации и автоматически обрабатывают такие вещи, как общие файлы cookie и единый вход (SSO).

На Android основными вариантами являются:

• Android WebView — это стандартный виджет WebView (android.webkit.WebView), который по сути представляет собой мини-браузер, который может быть встроен в ваши активности. Он легко настраивается, но работает в процессе вашего приложения.
• Chrome Custom Tabs (CCT) — это функция, которая открывает вкладку на базе Chrome в контексте вашего приложения. Custom Tabs выглядят как часть вашего приложения, но работают на базе браузера Chrome (если он установлен) с такими функциями, как предварительная загрузка, общие файлы cookie и знакомая адресная строка для доверия пользователей.

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

Подпишитесь на наш Passkeys Substack, чтобы получать новости.

Подписаться

Платформа Apple предоставляет три варианта WebView, перечисленные выше. Ваш выбор повлияет на то, насколько плавно можно будет использовать ключи доступа внутри приложения:

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

WKWebView — это универсальный компонент WebView для iOS. Разработчики могут встроить WKWebView для отображения веб-контента с высокой степенью контроля над UI и поведением. WKWebView использует тот же движок рендеринга, что и Safari, поэтому он очень производителен и поддерживает современные веб-функции. Теоретически, WKWebView может работать с WebAuthn (и, следовательно, с ключами доступа) при правильной настройке, но обратите внимание, что некоторые расширенные функции браузера могут быть ограничены в целях безопасности. Следует иметь в виду, что WKWebView по умолчанию не делится файлами cookie или данными связки ключей с Mobile Safari. Пользователям может потребоваться войти в систему заново, потому что их сеанс WebView изолирован от сеанса Safari. Кроме того, поскольку контент WKWebView может быть полностью настроен приложением, пользователь не видит адресную строку или UI Safari — это отлично для брендинга, но означает, что у пользователя меньше подсказок для проверки подлинности страницы (что вызывает опасения по поводу фишинга). Некоторые приложения даже злоупотребляли WKWebView для внедрения скриптов или изменения контента (например, было замечено, что TikTok внедряет отслеживающий JS через свой встроенный браузер), поэтому необходимо быть осторожным, чтобы использовать WKWebView безопасным и вызывающим доверие у пользователей образом.

SFSafariViewController обеспечивает опыт Safari внутри приложения. Когда вы открываете URL с помощью SFSafariViewController, это почти то же самое, что и открыть его в реальном браузере Safari, за исключением того, что пользователь остается в UI вашего приложения. Преимущество для ключей доступа значительно: поскольку это по сути Safari, пользователю доступны iCloud Keychain и сохраненные ключи доступа. Обратите внимание, что файлы cookie не общие в iOS 11+. Это означает, что если у пользователя уже есть ключ доступа для вашего сайта, Safari может найти его и даже отобразить автозаполнение Conditional UI для простого входа. SFSafariViewController менее настраиваемый (вы не можете сильно изменить его панель инструментов), но он автоматически обрабатывает множество функций безопасности и конфиденциальности. Адресная строка отображается вместе со значком замка для HTTPS, что дает пользователям уверенность в том, что они находятся в правильном домене. В целом, SFSafariViewController считается более безопасным, чем обычный WKWebView, и его проще реализовать (Apple предоставляет его как готовое решение). Главный компромисс заключается в том, что вы жертвуете некоторым контролем над внешним видом и ощущением. Для процесса аутентификации это обычно приемлемо. Приоритетом здесь является безопасность и простота входа в систему, с чем SFSafariViewController отлично справляется, используя контекст Safari.

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

Преимущество заключается в бесшовном опыте SSO — если пользователь уже вошел к провайдеру в Safari, этот сеанс может использовать этот файл cookie, чтобы избежать повторного входа. Для ключей доступа это важно, потому что это означает, что любой ключ доступа, сохраненный в Safari/iCloud Keychain, может быть использован и здесь. Официальное руководство Apple рекомендует использовать ASWebAuthenticationSession для всего, что похоже на процесс входа. Плюсы — повышенная конфиденциальность (ваше приложение никогда не видит учетные данные или файлы cookie, Safari обрабатывает их) и встроенная поддержка SSO. Минус в том, что он ограничен процессами аутентификации (вы не стали бы использовать его просто для рендеринга произвольного веб-контента в вашем приложении). В итоге, если вы выбираете подход WebView на iOS, ASWebAuthenticationSession обычно является лучшим выбором для реализации ключей доступа, потому что он безопасен, разделяет состояние с Safari и специально создан для аутентификации.

Посмотрите, сколько людей действительно используют passkeys.

Посмотреть данные внедрения

На Android решение о WebView принимается между классическим WebView и Chrome Custom Tabs:

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

Android WebView (android.webkit.WebView) — это компонент, который позволяет вам встраивать веб-страницы в макет вашей активности. Он похож на WKWebView в том, что дает вам полный контроль: вы можете перехватывать навигацию, внедрять JavaScript, настраивать UI и т. д. Он также работает внутри процесса вашего приложения. Использование WebView для ключей доступа означает, что ваше приложение загружает веб-страницу входа, и эта страница может инициировать церемонию WebAuthn для ключа доступа. Современный Android WebView действительно поддерживает WebAuthn (при условии, что реализация WebView на устройстве обновлена через Android System WebView или компонент Chrome). Одно важное соображение: по умолчанию Android WebView не делится файлами cookie или сохраненными учетными данными с браузером Chrome пользователя. Таким образом, любой ключ доступа, созданный или использованный в WebView, может быть неизвестен Chrome, и наоборот. Эта изоляция может быть хорошей для безопасности (ваше приложение не может читать файлы cookie браузера), но она может заставить пользователей снова войти в систему, если они уже аутентифицировались в Chrome. Другая проблема — это доверие. Обычный WebView не показывает URL или значок замка SSL, поэтому пользователи должны полностью доверять вашему приложению, что оно их не обманет. Google даже запретил использование WebView для входа через Google OAuth из-за потенциальных рисков фишинга. С точки зрения производительности, WebView работают нормально, но они могут быть медленнее или требовать больше памяти, чем использование браузера пользователя по умолчанию, особенно при загрузке тяжелых страниц.

Chrome Custom Tabs (CCT) — это гибридный подход. Они позволяют вашему приложению открывать страницу, отрисованную Chrome, которая выглядит как часть вашего приложения. Вы можете настроить цвет панели инструментов, добавить логотип приложения и т. д., но контент отображается Chrome в отдельном процессе. Для ключей доступа CCT имеют несколько преимуществ: они делятся файлами cookie пользователя и учетными данными с Chrome, что означает, если у пользователя есть ключ доступа, сохраненный через Chrome (Google Password Manager), Custom Tab может получить к нему доступ. Пользователь также увидит фактический URL и индикаторы безопасности, что укрепляет доверие. Производительность часто лучше — Chrome может быть "разогрет" в фоновом режиме для более быстрой загрузки. И, что важно, безопасность высокая: поскольку это по сути приложение Chrome, такие вещи, как Google Safe Browsing, защищают сеанс, и ваше приложение не может внедрять произвольные скрипты на страницу (предотвращая некоторые атаки).

Недостатком является то, что это требует от пользователя наличия установленного и обновленного Chrome (или поддерживаемого браузера). У большинства пользователей Android он есть, но на некоторых устройствах в определенных регионах это может быть проблемой. В целом, если вы выбираете встроенный веб-подход на Android, Chrome Custom Tabs рекомендуются для процессов работы с ключами доступа, так как они обеспечивают хороший баланс между интеграцией и безопасностью. Фактически, они во многом аналогичны SFSafariViewController/ASWebAuthSession в iOS, используя браузер по умолчанию для аутентификации.

(Отступление: WKWebView от Apple по сравнению со SFSafariViewController и Android WebView по сравнению с CCT имеют много параллелей. Как Safari VC, так и Chrome Tabs разделяют состояние браузера и обеспечивают лучшую безопасность, тогда как WKWebView/Android WebView дают больше контроля, но изолируют веб-контент. Для ключей доступа совместное использование состояния (файлы cookie, хранилища учетных данных) обычно желательно, чтобы ключ доступа можно было получить и создать беспрепятственно.)

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

Примечание об управляемых устройствах: Поведение ключей доступа значительно меняется на управляемых устройствах, где политики Mobile Device Management (MDM) контролируют хранение учетных данных.

Нативные и встроенные процессы WebView требуют файлов ассоциации для установления криптографического доверия между вашим приложением и веб-доменом. Системный WebView (ASWebAuthenticationSession) и Chrome Custom Tabs не требуют привязки приложения к сайту.

Файл AASA устанавливает связь между вашим приложением iOS и вашим веб-доменом, позволяя ключам доступа работать на обеих платформах.

Расположение файла: https://yourdomain.com/.well-known/apple-app-site-association

Требования к конфигурации:

• Разместить в /.well-known/apple-app-site-association на вашем домене
• Обслуживать по HTTPS с действительным SSL-сертификатом
• Content-Type: application/json
• Никаких редиректов на пути .well-known
• Включить Team ID и Bundle ID вашего приложения

Пример файла AASA:

{
    "webcredentials": {
        "apps": ["TEAMID123.com.example.app"]
    }
}

Кэширование AASA и тестирование:

Apple агрессивно кэширует файлы AASA (до 24-48 часов) с использованием CDN, что может затруднить разработку и тестирование. Чтобы обойти кэширование во время разработки:

1. Включите Developer Mode на вашем тестовом устройстве
2. Добавьте ?mode=developer к вашему связанному домену в Xcode
3. Это заставит iOS получать последний файл AASA напрямую с вашего сервера

⚠️ Важно: НЕ используйте ?mode=developer в производственных релизах. Этот параметр предназначен только для разработки — его использование в производстве не позволит iOS правильно обнаружить ваш файл AASA, что нарушит функциональность ключей доступа.

Валидация: Используйте валидатор AASA от Apple, чтобы проверить вашу конфигурацию.

Android использует Digital Asset Links для проверки взаимосвязи между вашим приложением и веб-сайтом.

Расположение файла: https://yourdomain.com/.well-known/assetlinks.json

Требования к конфигурации:

• Разместить в /.well-known/assetlinks.json на вашем домене
• Обслуживать по HTTPS с действительным сертификатом
• Content-Type: application/json
• Включить отпечаток SHA256 вашего приложения (из сертификата подписи)

Пример файла assetlinks.json:

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.example.app",
            "sha256_cert_fingerprints": [
                "AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99"
            ]
        }
    }
]

Валидация: Используйте генератор Digital Asset Links от Google, чтобы создать и проверить вашу конфигурацию.

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

Файл прав (часто называемый Runner.entitlements в приложениях Flutter или YourApp.entitlements в нативных проектах iOS) определяет специальные разрешения и возможности, предоставляемые системой Apple. Для ключей доступа этот файл настраивает Associated Domains.

Расположение файла: Обычно в вашем проекте Xcode в ios/Runner/Runner.entitlements

Нативная реализация и встроенный WebView требуют возможности Associated Domains для связи вашего приложения с вашим веб-доменом. Системный WebView (ASWebAuthenticationSession) не требует этого, так как он работает в контексте Safari.

Настройка в Xcode:

1. Откройте ваш проект в Xcode
2. Выберите цель вашего приложения
3. Перейдите на вкладку "Signing & Capabilities"
4. Нажмите "+ Capability" и добавьте "Associated Domains"
5. Добавьте ваш домен с префиксом webcredentials:

Пример конфигурации:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.developer.associated-domains</key>
    <array>
        <string>webcredentials:yourdomain.com</string>
        <string>webcredentials:subdomain.yourdomain.com</string>
    </array>
</dict>
</plist>

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

Встроенные WebView на Android поддерживают ключи доступа двумя различными способами: более новый подход на основе WebKit (Раздел 5.3.1) и старый подход через JavaScript bridge (Раздел 5.3.2). Системный WebView (Chrome Custom Tabs) не требует никакой настройки — учетные данные работают автоматически.

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

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

Официальный пример: Webkit WebView MainActivity

Требования:

• AndroidX WebKit 1.12.1 или новее (рекомендуется 1.14.0+)
• Настроенные Digital Asset Links
• APK WebView с поддержкой WebAuthn (проверить через определение функций)
• Примечание: Библиотека AndroidX Credentials НЕ требуется для WebView WebAuthn, только для полностью нативных реализаций

Реализация:

import androidx.webkit.WebSettingsCompat
import androidx.webkit.WebViewFeature
 
// Check if Web Authentication is supported
if (WebViewFeature.isFeatureSupported(WebViewFeature.WEB_AUTHENTICATION)) {
    // Enable Web Authentication
    WebSettingsCompat.setWebAuthenticationSupport(
        webView.settings,
        WebSettingsCompat.WEB_AUTHENTICATION_SUPPORT_FOR_APP
    )
 
    // Enable JavaScript
    webView.settings.javaScriptEnabled = true
}

Ключевые моменты:

• JavaScript bridge не нужен: WebAuthn работает нативно в WebView
• Требуется определение функций: Всегда проверяйте WebViewFeature.WEB_AUTHENTICATION во время выполнения
• Conditional UI не поддерживается: mediation:"conditional" (автозаполнение ключей доступа в полях ввода) не работает во встроенном WebView
• Стратегия резервного копирования: Если функция недоступна, используйте вместо этого Chrome Custom Tabs

Примечания к версиям:

• Используйте WebKit 1.12.1 или новее (в 1.12.0 была проблема с доступностью во время выполнения)
• Поддержка функций зависит от версии APK WebView пользователя — старые APK на устройстве не будут предоставлять эту функцию

До AndroidX WebKit 1.12.0 встроенной поддержки WebAuthn во встроенном WebView не было. В этом старом подходе используется мост Web-to-Native для обработки ключей доступа на устройствах без нативной поддержки WebView WebAuthn.

Официальные примеры:

• PasskeyWebListener (Обработчик моста)
• Утилиты кодирования JavaScript

Когда использовать: Поддержка старых версий Android или устройств с устаревшими реализацияями WebView.

Командам приходилось либо:

1. Использовать Chrome Custom Tabs или Auth Tab (рекомендуется)
2. Создавать пользовательский JavaScript bridge

Однако мы настоятельно рекомендуем использовать нативный подход WebKit 1.12.1+ для современных приложений.

Рекомендация: Используйте нативную поддержку WebAuthn с AndroidX WebKit 1.12.1+. Если она недоступна во время выполнения, вернитесь к Chrome Custom Tabs, который обеспечивает отличную поддержку ключей доступа с общими учетными данными.

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

Для приложений, использующих один домен (например, kayak.com), вам необходимо:

• Один файл AASA для iOS на https://kayak.com/.well-known/apple-app-site-association
• Один assetlinks.json для Android на https://kayak.com/.well-known/assetlinks.json
• Право Associated Domains, настроенное с webcredentials:kayak.com

Связанные источники (ROR) — это функция WebAuthn, которая позволяет единому набору ключей доступа работать на нескольких связанных доменах (например, kayak.com, kayak.de, kayak.co.uk). ROR использует конечную точку /.well-known/webauthn на каждом сайте для определения связанных источников, а НЕ файлы AASA или assetlinks.

Ключевые моменты:

• Конфигурация ROR: Каждый домен размещает /.well-known/webauthn со списком связанных источников
• Файлы ассоциации приложения (AASA/assetlinks): Используются только для сопоставления приложений с соответствующими веб-сайтами
• Встроенный WebView в iOS 18+: Поддерживает ROR при правильной настройке
• Права Associated Domains: Включите все домены, с которыми ваше приложение должно аутентифицироваться

Пример конфигурации:

Если ваше приложение работает с kayak.com и kayak.de, оба домена должны:

• Разместить свои соответствующие файлы AASA с одинаковыми Team ID и Bundle ID
• Быть перечислены в правах Associated Domains вашего приложения
• Иметь правильно настроенные и доступные известные файлы

Перед запуском убедитесь, что ваши известные файлы правильно настроены и доступны. Apple и Google предоставляют тестовые URL на базе CDN для проверки доступности файлов:

Использование этих тестовых URL:

• Нажмите на ссылки, чтобы убедиться, могут ли Apple/Google получить ваши известные файлы
• Параметр ?nocache=1 от Apple принудительно выполняет свежее получение, обходя кэш CDN
• Если файлы недоступны по этим URL, функциональность ключей доступа не будет работать в вашем приложении
• Замените kayak.com или kayak.de на ваш(и) собственный(ые) домен(ы) в шаблонах URL выше

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

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

Следующая блок-схема поможет вам выбрать правильный подход к реализации на основе требований вашего приложения:

Краткий справочник для каждого пути:

• Вход через OAuth? → Системный WebView (ASWebAuthenticationSession / Chrome Custom Tabs)
• Повторно использовать веб-аутентификацию в нативной оболочке? → Встроенный WebView с конфигурацией (WKWebView / Android WebView + WebKit 1.12.1+)
• Создаете нативное приложение с нуля? → Нативная реализация (AuthenticationServices / Credential Manager)
• Существующая веб-аутентификация для повторного использования? → Системный WebView для быстрой реализации; в противном случае нативная для оптимального UX

Вот как каждый подход работает по ключевым параметрам:

Объяснение параметров:

• Создание ключей доступа: Насколько легко пользователи могут создавать ключи доступа с помощью этого подхода
• Использование ключей доступа: Опыт аутентификации при использовании существующих ключей доступа
• Управление ключами доступа: Как пользователи просматривают, редактируют или удаляют ключи доступа
• Техническая сложность: Усилия по разработке и текущее обслуживание
• Поддержка OAuth: Насколько хорошо подход обрабатывает процессы аутентификации OAuth2/OIDC
• Время на настройку: Типичные сроки реализации

Рекомендуется: Системный WebView

Если ваше приложение аутентифицируется через OAuth2, OIDC или провайдеров входа через соцсети (Google, GitHub, Microsoft и т. д.), системный WebView — оптимальный выбор:

• iOS: ASWebAuthenticationSession специально создан для процессов OAuth
• Android: Chrome Custom Tabs обеспечивают бесшовную интеграцию OAuth
• Преимущества: Минимальный нативный код, автоматическое совместное использование учетных данных
• Реализация: Добавьте WebAuthn на свою веб-страницу аутентификации, затем загрузите ее через системный WebView

Пример: Приложения для путешествий, такие как kayak.com и kayak.de, используют OAuth для аутентификации. Системный WebView позволяет им поддерживать существующую инфраструктуру OAuth, добавляя при этом поддержку ключей доступа через свои веб-страницы аутентификации.

Рекомендуется: Гибридный подход

Используйте системный WebView для первоначальной аутентификации OAuth, а затем встроенный WebView для сеансов после аутентификации:

1. Первоначальная аутентификация: Системный WebView обрабатывает OAuth + вход по ключу доступа
2. Управление сессиями: Переключитесь на встроенный WebView для аутентифицированного веб-контента, где требуется контроль файлов cookie/сеансов
3. Техническая настройка: Настройте требования как для системного, так и для встроенного WebView — для Android убедитесь, что включен AndroidX WebKit 1.12.1+ (см. Раздел 5)

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

Рекомендуется: Нативная реализация

Строите с нуля или имеете нативные экраны? Выбирайте полностью нативный вариант:

• iOS: Используйте фреймворк AuthenticationServices
• Android: Используйте Credential Manager API
• Преимущества: Лучший UX, мгновенная аутентификация, полный контроль
• Уникальное преимущество: Используйте preferImmediatelyAvailableCredentials для отображения автоматического оверлея ключей доступа при запуске приложения — эксклюзивно для нативных реализаций и обеспечивает самые высокие коэффициенты конверсии
• Рекомендация по SDK: Используйте SDK Corbado (iOS, Android) для ускорения разработки с обработкой пограничных случаев, проверенной в производстве

Для новых приложений: Настоятельно рекомендуем создавать нативный вход с первого дня. Это настраивает вас на оптимальный UX и позволяет избежать будущих миграций с WebView на нативные компоненты.

Рекомендуется: Поэтапная миграция

Следующая диаграмма показывает поэтапный путь миграции:

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

Подробные инструкции по настройке см. в Разделе 5.

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

Основные категории тестов:

• Основные пути: Регистрация, аутентификация, кросс-платформенные процессы, удаление ключей доступа
• Охват платформ: iOS (нативный), Android (нативный), веб-браузеры на разных версиях ОС
• Ассоциация доменов: Убедитесь, что файлы AASA (iOS) и Digital Asset Links (Android) доступны
• Процессы отмены: Тестируйте отмену пользователем на системных подсказках и биометрических экранах
• Обработка ошибок: Сбои бэкенда, таймауты сети, несоответствия учетных данных
• Граничные случаи: Блокировка экрана отключена, iCloud/Google Password Manager отключен
• Процессы OAuth: Сквозное тестирование полной интеграции OAuth + ключи доступа
• Управляемые устройства: Среды, контролируемые MDM (см. тестирование управляемых устройств)
• Сторонние менеджеры: Совместимость с 1Password, Bitwarden, Dashlane
• Кросс-устройственная аутентификация: Процессы с QR-кодом и тестирование гибридного транспорта
• Специфика встроенного WebView: Если используется встроенный WebView, проверьте конфигурацию WebKit 1.12.1+ на Android
• Мониторинг в производстве: Панель инструментов для показателей успешности, сбоев и задержек

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

Рассмотрите возможность предложения пользователям создать ключи доступа после успешного традиционного входа (пароль, OAuth). Этот подход постепенной конверсии:

• Не нарушает существующие процессы аутентификации
• Позволяет изящно снизить требования, если пользователь отказывается
• Со временем увеличивает принятие ключей доступа без принудительных изменений
• Хорошо работает со всеми тремя подходами к реализации

Пример: После входа через OAuth через системный WebView покажите нативную подсказку: "Включить более быстрый вход с Face ID?". В случае согласия создайте ключ доступа через веб-страницу, загруженную в системном WebView.

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

Для приложений на базе OAuth: Системный WebView (ASWebAuthenticationSession, Chrome Custom Tabs) — рекомендуемая отправная точка. Он обеспечивает отличную поддержку OAuth, минимальные усилия по реализации и автоматическое совместное использование учетных данных.

Для нативных приложений: Лучше перейти на нативную реализацию раньше, чем позже. Нативный вход по ключу доступа предлагает наиболее бесшовный UX с эксклюзивными возможностями, такими как preferImmediatelyAvailableCredentials, который обеспечивает автоматический оверлей ключей доступа при запуске приложения — то, что не могут предоставить реализации WebView. Теперь, когда iOS и Android обеспечивают первоклассную поддержку ключей доступа, реальные успехи демонстрируют высокое принятие. Инструменты (включая SDK с открытым исходным кодом и библиотеки платформ) созрели, чтобы сделать нативную интеграцию достижимой в разумные сроки. Хотя вы должны помнить о политиках управления устройствами, синхронизации между устройствами и сторонних провайдерах, этими проблемами можно управлять с помощью тщательной инженерии и тестирования. В результате получается вход в приложение, который радует пользователей своей простотой и скоростью, значительно повышая при этом безопасность.

Для требований к кадрам встроенного WebView: Встроенный WebView обычно используется в двух реальных сценариях. Во-первых, приложения на базе OAuth часто используют системный WebView для первоначального процесса входа, а затем переключаются на встроенный WebView для отображения параметров управления ключами доступа на экранах настроек, где требуется контроль сеанса — хотя некоторые приложения упрощают это, оставляя системный WebView для обоих процессов. Во-вторых, приложения, которые уже встроили свой процесс аутентификации во фреймы WebView до принятия ключей доступа, продолжают этот шаблон для единообразия. Встроенный WebView с нативной поддержкой WebAuthn (AndroidX WebKit 1.12.1+) требует конфигурации и настройки (разрешения, права, настройки WebView), но больше не нуждается в пользовательском коде JavaScript bridge. Обратите внимание, что Conditional UI не поддерживается во встроенном WebView. Выбирайте этот подход при поддержании существующих шаблонов встроенной аутентификации или когда вам нужен контроль сеанса/файлов cookie для экранов после аутентификации.

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

Если ключи доступа не работают в вашем нативном приложении, проверьте эти распространенные проблемы по подходам к реализации:

• Файлы обслуживаются по HTTPS с действительным сертификатом
• Правильный тип MIME: application/json
• Никаких редиректов на пути .well-known
• iOS: Team ID и Bundle ID точно совпадают в файле AASA
• Android: Отпечаток SHA256 совпадает с вашим сертификатом подписи в assetlinks.json
• Relying Party ID соответствует вашему домену (без протокола, без порта)
• Нет конечных косых черт в RP ID
• Источник WebAuthn: https://your-domain.com (не app://)

• iOS: Возможность Associated Domains включена в Xcode с webcredentials:yourdomain.com
• Android: Digital Asset Links объявлены в AndroidManifest.xml
• У пользователя включена блокировка экрана (биометрия или PIN)
• Протестируйте с помощью валидатора AASA от Apple и инструмента Digital Asset Links от Google
• Убедитесь, что файл Runner.entitlements содержит правильные связанные домены

• iOS: Используется ASWebAuthenticationSession (рекомендуется) или SFSafariViewController
• Android: Используется Chrome Custom Tabs (не обычный WebView)
• iOS: Убедитесь, что Associated Domains настроены, если это необходимо
• Проверьте, что файлы cookie/учетные данные делятся с системным браузером
• Убедитесь, что веб-страница аутентификации имеет правильную реализацию WebAuthn

• iOS: Настроен с соответствующими правами
• iOS: Associated Domains включают все соответствующие домены
• iOS: Файл AASA доступен и правильно отформатирован
• iOS: Тестирование с ?mode=developer во время разработки (удалить для производства)
• Android: В проект включен AndroidX WebKit 1.12.1+ (или новее)
• Android: Проверка во время выполнения для WebViewFeature.WEB_AUTHENTICATION
• Android: Вызван setWebAuthenticationSupport() с WEB_AUTHENTICATION_SUPPORT_FOR_APP
• Android: JavaScript включен в настройках WebView
• Android: Версия APK WebView пользователя поддерживает функцию WebAuthn (используйте определение функций, а не версию ОС)
• Conditional UI не используется (не поддерживается во встроенном WebView)
• Резервный вариант Chrome Custom Tabs, если функция WebAuthn недоступна

• Проверьте, активен ли у пользователя нестандартный провайдер учетных данных (1Password, Bitwarden и т. д.)
• Убедитесь, что провайдер поддерживает ключи доступа (не все менеджеры паролей это делают)
• Тестируйте с нативным менеджером учетных данных платформы (iCloud Keychain, Google Password Manager)

"NotAllowedError: The request is not allowed by the user agent or the platform in the current context"

• Обычно означает: Отсутствуют права (iOS) или функция WebView недоступна/не включена (Android Embedded WebView)
• Проверьте: Конфигурацию Associated Domains, доступность файла AASA, версию WebKit, определение функций, вызов setWebAuthenticationSupport()

Не появляется запрос на ввод ключа доступа

• Может означать: AASA/assetlinks.json не загружается, неверный тип WebView, кэшированный файл AASA
• Попробуйте: Проверить файлы ассоциации, использовать ?mode=developer на iOS для тестирования, проверить тип WebView

Для детальной отладки смотрите нашу статью о Relying Party IDs в нативных приложениях.

Распространенная ошибка: staging-среды с ограниченным доступом (белые списки IP, только VPN) будут давать сбой, потому что CDN Apple и Google должны иметь возможность получать ваши файлы ассоциации.

• Файлы AASA/assetlinks публично доступны (нет белых списков IP, нет требований VPN)
• Убедитесь, что CDN Apple может получить доступ к вашему файлу: https://app-site-association.cdn-apple.com/a/v1/your-staging-domain.com?nocache=1
• Убедитесь, что Google может получить доступ к вашему файлу: https://digitalassetlinks.googleapis.com/v1/statements:list/?source.web.site=https://your-staging-domain.com&relation=delegate_permission/common.handle_all_urls

Поддомен Staging с production rpID:

Если ваша staging-среда (например, stg.login.example.com) использует production-домен в качестве rpID (например, example.com), поиск AASA происходит на домене rpID, а не на вашем staging-поддомене. Это означает:

• Добавьте идентификаторы пакетов (bundle IDs) staging-приложения в ваш production файл AASA
• Имейте в виду, что ключи доступа, созданные на staging, будут появляться в процессах входа на production (потенциальная путаница)

Пример (несколько сред делят один AASA):

{
    "webcredentials": {
        "apps": [
            "TEAMID123.com.example.app",
            "TEAMID123.com.example.app.dev",
            "TEAMID123.com.example.app.stg",
            "TEAMID123.com.example.app.pre"
        ]
    }
}

Рекомендация: Используйте отдельный staging rpID, соответствующий вашему staging-домену, чтобы избежать перекрытия учетных данных между средами. Это требует публично доступных файлов AASA на staging-домене.

Пояснение ?mode=developer:

Параметр ?mode=developer в Associated Domains обходит кэш CDN Apple, но не обходит требование доступности. Ваш файл AASA по-прежнему должен быть доступен с устройства (не через CDN Apple, а напрямую). Это помогает во время разработки при итерациях над изменениями AASA, но не поможет, если ваш staging-сервер находится в белом списке IP.

Нативные SDK Corbado:

• iOS SDK (Swift)
• Android SDK (Kotlin)
• Flutter Package

Документация платформы:

• Apple: Поддержка ключей доступа
• Google: Credential Manager

Инструменты валидации:

• Валидатор AASA от Apple
• Генератор Digital Asset Links от Google

О Corbado

Corbado — это Passkey Intelligence Platform для CIAM-команд, обеспечивающих аутентификацию пользователей в крупных масштабах. Мы показываем то, что не видят логи IDP и общие инструменты аналитики: какие устройства, версии ОС, браузеры и менеджеры учётных данных поддерживают passkey, почему регистрации не превращаются в логины, где сбоит WebAuthn-поток и когда обновление ОС или браузера тихо ломает вход — всё это без замены Okta, Auth0, Ping, Cognito или вашего собственного IDP. Два продукта: Corbado Observe добавляет наблюдаемость для passkey и любых других способов входа. Corbado Connect даёт managed passkey со встроенной аналитикой (рядом с вашим IDP). VicRoads использует passkey для более чем 5 млн пользователей с Corbado (+80 % активации passkey). Поговорить с экспертом по passkey →

Выбор зависит от архитектуры вашей аутентификации. Если ваше приложение использует OAuth2 или OIDC, системный WebView (ASWebAuthenticationSession на iOS или Chrome Custom Tabs на Android) требует наименьших усилий по реализации и не требует настройки файлов ассоциации. Для новых нативных приложений нативная реализация обеспечивает превосходный UX, тогда как встроенный WebView подходит для приложений, которые уже встраивают аутентификацию во фрейм WebView и нуждаются в контроле сеанса или файлов cookie после входа.

SFSafariViewController использует движок Safari, показывает адресную строку с индикаторами SSL и обеспечивает защиту от фишинга, что делает его более заслуживающим доверия для процессов аутентификации. WKWebView предлагает больше возможностей настройки UI, но имеет изолированное хранилище файлов cookie отдельно от Safari, требует прав Associated Domains и файла AASA для включения ключей доступа, и не отображает адресную строку, что снижает сигналы доверия пользователей.

Chrome Custom Tabs делятся файлами cookie и сохраненными учетными данными с браузером Chrome пользователя, что означает, что ключи доступа, сохраненные в Google Password Manager, доступны во время аутентификации. Стандартный Android WebView имеет изолированное хранилище файлов cookie, не показывает URL или индикаторы SSL, и Google прямо запретил его для входа в учетные записи Google из-за рисков фишинга.

Если у пользователя сторонний менеджер учетных данных, такой как 1Password, установлен в качестве активного провайдера, он часто перехватывает создание и хранение ключей доступа, имея приоритет над нативным менеджером учетных данных платформы (iCloud Keychain или Google Password Manager). Это означает, что ключи доступа могут храниться в стороннем приложении, а не в связке ключей платформы, что влияет на синхронизацию между устройствами и поведение управления ключами доступа.

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