Транспорты WebAuthn: внутренний и гибридный

Passkeys for Super Funds and Financial Institutions
Join our Webinar on 7th November to learn how Super Funds and Financial Institutions can implement passkeys

Join now

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

При внедрении Passkeys на разных платформах перед разработчиками встает важный вопрос:

• Как следует обрабатывать транспорты WebAuthn, особенно внутренний (internal) и гибридный (hybrid), чтобы обеспечить оптимальный опыт кросс-девайсной аутентификации?

Ответ кроется в понимании транспортов WebAuthn — технической детали, которая определяет, как аутентификаторы взаимодействуют с доверяющими сторонами. Хотя в теории транспорты кажутся простыми, их реализация значительно различается в веб-браузерах, нативных приложениях iOS и Android, особенно в части обработки internal и hybrid транспортов.

В этой статье мы рассмотрим, как транспорты WebAuthn работают на разных платформах, и представим два разных подхода к обработке внутреннего и гибридного транспортов, каждый со своими компромиссами.

Эта статья охватывает:

1. Транспорты WebAuthn: internal, hybrid и платформенные аутентификаторы в вебе, на iOS и Android
2. Два подхода: соответствующий спецификации и оптимизированный способы обработки internal и hybrid транспортов
3. Лучшие практики и рекомендации по реализации кросс-девайсной аутентификации

Транспорты WebAuthn определяют методы связи между аутентификаторами и клиентскими устройствами. Спецификация WebAuthn Level 3 определяет шесть типов транспортов:

usb: Используется аппаратными ключами безопасности, которые подключаются через USB-порты, например, YubiKeys или другие токены FIDO2.

nfc: Позволяет взаимодействовать с аутентификаторами через Near Field Communication, давая пользователям возможность прикладывать свои ключи безопасности или устройства с поддержкой NFC.

ble: Обеспечивает аутентификацию через Bluetooth Low Energy, позволяя беспроводную связь с внешними аутентификаторами.

smart-card: Используется для считывателей смарт-карт, позволяя аутентификацию с помощью смарт-карт.

hybrid: Позволяет выполнять кросс-девайсную аутентификацию, обычно когда пользователь сканирует QR-код для аутентификации на разных устройствах, например, используя телефон для входа в браузере на компьютере или наоборот. Этот транспорт может вызывать отображение QR-кода как на настольных, так и на мобильных устройствах, что не всегда желательно в зависимости от контекста. Примечание: hybrid был добавлен в WebAuthn Level 3.

internal: Аутентификатор встроен в само устройство — например, iCloud Keychain (проверка через Face ID или Touch ID) на iPhone, Windows Hello на ПК или Google Password Manager на устройствах Android. Это платформенные аутентификаторы.

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

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

Браузеры получают информацию о транспортах от аутентификаторов и учитывают ее в процессе аутентификации. Когда вы создаете Passkey в Chrome, Safari или Edge, менеджер учетных данных браузера предоставляет данные о транспортах, которые различаются в зависимости от используемого аутентификатора:

Платформенные аутентификаторы: Windows Hello предоставляет только ["internal"], что отражает его привязку к устройству. Однако, когда Chrome использует Google Password Manager в качестве аутентификатора, он предоставляет ["internal", "hybrid"], поскольку Google Password Manager поддерживает кросс-девайсную аутентификацию через телефоны Android.

Аппаратные ключи безопасности: Предоставляют конкретные транспорты, такие как ["usb", "nfc"], в зависимости от их реальных возможностей.

Менеджеры учетных данных с облачной синхронизацией: iCloud Keychain в Safari и Google Password Manager в Chrome обычно предоставляют ["internal", "hybrid"] для поддержки как локальной, так и кросс-девайсной аутентификации.

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

Документация: Спецификация W3C WebAuthn

API Credential Manager в Android ведет себя аналогично веб-браузерам. При создании Passkeys в нативных приложениях Android Credential Manager предоставляет информацию о транспортах, которая отражает поведение в вебе — платформенные аутентификаторы точно сообщают о своих возможностях, и система последовательно обрабатывает данные о транспортах. Разработчики Android могут полагаться на эту информацию без специальной обработки.

Документация: Android Credential Manager

Ситуация с iOS сложнее. Фреймворк AuthenticationServices от Apple обрабатывает транспорты по-разному в зависимости от типа аутентификатора:

Платформенные аутентификаторы (iCloud Keychain, проверка через Face ID или Touch ID): Часто возвращают пустые массивы транспортов во время создания Passkey. Это не означает, что у Passkey нет транспортных возможностей — это просто значит, что iOS не сообщает о них явно. Согласно стандарту WebAuthn, отсутствие транспортов означает, что любой транспорт приемлем, поэтому гибридная аутентификация все равно будет работать.

Аппаратные ключи безопасности: Предоставляют информацию о транспортах (например, ["usb"], ["nfc"]) при использовании с устройствами iOS, следуя ожидаемому шаблону.

Документация: Apple AuthenticationServices

Перед разработчиками стоит выбор: строго следовать спецификации или оптимизировать internal и hybrid транспорты для улучшения пользовательского опыта. У каждого подхода есть свои достоинства и недостатки.

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

Реализация: При создании Passkey сохраняйте массив transports из ответа аутентификатора. Во время аутентификации включайте эти же транспорты в список allowCredentials:

{
    "allowCredentials": [
        {
            "id": "credential-id-base64",
            "type": "public-key",
            "transports": ["internal", "hybrid"]
        }
    ]
}

Преимущества:

• Соответствие спецификации: Точно следует стандартам WebAuthn, обеспечивая совместимость с будущими обновлениями платформ.
• Надежность аппаратных ключей: Отлично работает с аппаратными ключами безопасности (YubiKeys и т.д.), которые всегда предоставляют точную информацию о транспортах.
• Предотвращает недействительные опции: Позволяет избежать предложения методов аутентификации, которые действительно не поддерживаются, например, не будет вызывать QR-коды для учетных данных Windows Hello.

Недостатки:

• Поведение iOS с пустым массивом: Платформенные аутентификаторы на iOS возвращают пустые транспорты, что согласно спецификации означает «любой транспорт». Это может привести к отображению всех вариантов аутентификации, включая аппаратные ключи.
• Может показывать нежелательные опции: Может предлагать опции аппаратных ключей безопасности (USB, NFC) в потребительских приложениях, где они не ожидаются.
• Непоследовательный пользовательский опыт: Разные платформы предлагают разные варианты аутентификации для одной и той же учетной записи.

Лучше всего подходит для: Приложений, где приоритетом является соответствие стандартам, и для корпоративных сред с разнообразными типами аутентификаторов.

Этот подход ставит в приоритет пользовательский опыт, выборочно изменяя internal и hybrid транспорты для достижения конкретных целей оптимизации. Вместо общего правила рассмотрим эти распространенные сценарии оптимизации:

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

Решение: Явно установить транспорты в ["hybrid", "internal"] для платформенных аутентификаторов iOS. Это гарантирует, что будут предложены только платформенная аутентификация и кросс-девайсные потоки, скрывая опции аппаратных ключей.

// При сохранении учетных данных платформенного аутентификатора iOS
if (platform === "iOS" && authenticatorAttachment === "platform") {
    transports = ["hybrid", "internal"];
}

Результат: Чистый интерфейс аутентификации без запросов на использование аппаратных ключей для Passkeys, созданных на iOS.

Проблема: При аутентификации на мобильных устройствах показ QR-кодов для кросс-девайсной аутентификации создает плохой UX — пользователи уже находятся на мобильном устройстве, где их Passkeys доступны.

Решение: Удалить транспорт hybrid, когда пользователь проходит аутентификацию с мобильного устройства, оставив только ["internal"].

// При формировании allowCredentials для аутентификации
const transports = isMobileDevice
    ? credentials.transports.filter((t) => t !== "hybrid")
    : credentials.transports;

Результат: Мобильные пользователи видят только прямые варианты аутентификации без ненужных запросов с QR-кодом.

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

• Некоторые платформы показывают QR-коды, даже если hybrid исключен из транспортов.
• Другие скрывают QR-коды, даже если hybrid включен.
• Поведение значительно варьируется между Chrome, Edge, Safari и Firefox на Windows, macOS и iOS.

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

Это лишь намеки на оптимизацию: WebAuthn предоставляет другие механизмы для оптимизации UX аутентификации помимо манипулирования транспортами, такие как подсказки (hints).

Поведение транспортов непредсказуемо: Кросс-девайсная аутентификация (CDA) через hybrid транспорт ведет себя непоследовательно в разных комбинациях браузеров и ОС. Тестирование в реальных условиях показывает, что значения транспортов не гарантируют определенного поведения UI — платформы интерпретируют и обрабатывают транспорты по-разному, что приводит к неожиданным результатам.

Сложность, специфичная для платформ: При явном управлении транспортами вы должны учитывать различия платформ:

• iOS: Отправляет пустые массивы для платформенных аутентификаторов; требует заполнения.
• Windows Hello: Должен оставаться только ["internal"]; добавление hybrid вызывает нежелательные QR-коды.
• Веб и Android: В целом предоставляют точную информацию о транспортах.
• Вариации CDA: Запросы QR-кодов могут появляться или исчезать независимо от наличия hybrid в массиве транспортов.

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

Преимущества:

• Адаптированный UX: Контролируйте, какие именно варианты аутентификации видят пользователи в конкретных контекстах.
• Решает проблему пустого массива в iOS: Явно определяет транспорты там, где iOS их не предоставляет.
• Контекстно-зависимая оптимизация: Адаптируйте UI аутентификации в зависимости от типа устройства.

Недостатки:

• Непредсказуемое поведение: Манипулирование транспортами не гарантирует последовательного поведения UI. Обширное тестирование показывает, что платформы интерпретируют транспорты по-разному, иногда показывая или скрывая опции независимо от значений транспортов.
• Риск тупиков в аутентификации: Слишком строгая фильтрация транспортов может полностью заблокировать аутентификацию для пользователей, особенно в кросс-девайсных сценариях.
• Отклонение от спецификации: Отход от рекомендаций спецификации может вызвать проблемы с будущими изменениями платформ.
• Бремя поддержки: Требует постоянной поддержки специфичной для платформы логики и обновлений по мере развития платформ.
• Сложность: Необходимо вручную обрабатывать пустые массивы iOS, ограничения Windows Hello и другие особенности платформ.
• Затраты на тестирование: Каждое правило оптимизации требует проверки на всех комбинациях платформ.

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

Обработка транспортов WebAuthn не существует в вакууме — это часть вашей общей стратегии внедрения Passkeys. В производственных развертываниях появляются два распространенных подхода, каждый с разными последствиями для использования internal и hybrid транспортов.

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

Характеристики реализации:

• UI аутентификации: Кнопка Passkey появляется рядом с существующими вариантами входа (имя пользователя/пароль).
• allowCredentials: Устанавливается в пустой массив [], позволяя любому учетному данным совпасть.
• Типы аутентификаторов: Поддерживаются аппаратные ключи безопасности, кросс-девайсная аутентификация (QR-коды) и платформенные аутентификаторы.
• Требования к нативным приложениям: Должны поддерживать все методы аутентификации, включая аппаратные ключи.
• preferImmediatelyAvailableCredentials: Не может использоваться, так как по определению исключает аппаратные ключи и вход по QR-коду.
• Обработка транспортов: Должна учитывать все типы транспортов, включая транспорты аппаратных ключей (usb, nfc, ble).

Последствия для транспортов:

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

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

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

Характеристики реализации:

• Создание Passkey: Разрешены только платформенные аутентификаторы через authenticatorAttachment: "platform".
• Поток аутентификации: Сначала идентификатор — пользователи вводят email/имя пользователя перед аутентификацией.
• allowCredentials: Заполняется конкретными учетными данными пользователя (не пустой) после того, как идентификатор известен.
• Типы аутентификаторов: Платформенные аутентификаторы и кросс-девайсная аутентификация; аппаратные ключи обычно исключены.
• Оптимизация нативных приложений: Можно использовать preferImmediatelyAvailableCredentials, который по определению исключает аппаратные ключи и кросс-девайсную аутентификацию.
• Кросс-девайсная аутентификация: Доступна в вебе; недоступна при использовании preferImmediatelyAvailableCredentials в нативных приложениях, но этот сценарий редок (пользователи обычно имеют Passkeys на используемом устройстве).
• Обработка транспортов: Сосредоточена только на internal и hybrid транспортах.

Последствия для транспортов:

Поскольку allowCredentials содержит конкретные учетные данные с их транспортами, обработка транспортов становится критически важной.

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

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

1. Бэкенд запрашивает существующие Passkeys.
2. Возвращает allowCredentials с конкретными учетными данными и их транспортами.
3. Платформа может оптимизировать UI аутентификации на основе транспортов.
4. Нет дополнительного риска перечисления учетных записей (идентификатор уже предоставлен).

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

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

Независимо от того, какой подход вы выберете для обработки internal и hybrid транспортов, следуйте этим практикам, чтобы минимизировать проблемы:

Сохраняйте транспорты при регистрации: Всегда сохраняйте массив transports из ответа аутентификатора вместе с ID учетных данных и публичным ключом. Эти данные необходимы для процессов аутентификации.

Корректно обрабатывайте пустые массивы: При получении пустого массива транспортов от платформенных аутентификаторов iOS:

• Соответствие спецификации: Оставляйте пустым или опускайте свойство transports — это означает, что «любой транспорт» приемлем.
• Подход с оптимизацией: Заполняйте ["internal", "hybrid"] для контроля над отображаемыми вариантами аутентификации.

Тестируйте на всех целевых платформах: Создайте матрицу тестирования, охватывающую все комбинации:

• Регистрация: Веб, нативные приложения iOS, нативные приложения Android.
• Аутентификация: Веб, нативные приложения iOS, нативные приложения Android.
• Проверяйте, что QR-коды появляются, когда ожидается, и скрыты, когда это неуместно.

Понимайте разницу между пустым массивом и отсутствующим свойством: И пустой массив [], и отсутствующее свойство transports обычно трактуются как «любой транспорт приемлем» согласно спецификации. Однако детали реализации могут различаться на разных платформах.

Следите за изменениями платформ: Реализации WebAuthn развиваются. Apple, Google и Microsoft регулярно обновляют поведение своих аутентификаторов. Будьте в курсе изменений, которые могут повлиять на обработку транспортов.

Транспорты WebAuthn — особенно internal и hybrid — это технические детали со значительным практическим влиянием на кросс-девайсную аутентификацию. Ваша стратегия обработки транспортов должна соответствовать вашему общему подходу к внедрению Passkeys и целевым платформам.

Решения о транспортах — часть общей стратегии: То, как вы обрабатываете транспорты, зависит от того, стремитесь ли вы к максимальной гибкости (пустой allowCredentials) или к потребительскому UX (сначала идентификатор, затем конкретные учетные данные). Последний вариант делает транспорты критически важными для оптимизации.

Различия платформ требуют обработки: Веб и Android предоставляют надежную информацию о транспортах, в то время как платформенные аутентификаторы iOS возвращают пустые массивы. Windows Hello отправляет только ["internal"]. Понимание этих различий необходимо для производственных развертываний.

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

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

Для корпоративных сред / максимальной гибкости:

• Используйте пустой allowCredentials для поддержки всех типов аутентификаторов.
• Доверяйте транспортам, предоставленным аутентификатором.
• Примите тот факт, что пользователи видят больше вариантов аутентификации.
• Более простая реализация, более широкая совместимость.

Для потребительских приложений / нативных приложений:

• Внедрите схему аутентификации с предварительным вводом идентификатора.
• Ограничьтесь платформенными аутентификаторами (authenticatorAttachment: "platform").
• Используйте allowCredentials с конкретными учетными данными и оптимизированными транспортами.
• Включите preferImmediatelyAvailableCredentials в нативных приложениях.
• Заполняйте пустые массивы iOS ["hybrid", "internal"].
• Фильтруйте hybrid на мобильных устройствах, чтобы предотвратить появление QR-кодов.
• Превосходный UX с оптимизированными вариантами аутентификации.

Для платформ, где уже используется схема с предварительным вводом идентификатора:

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

Начните с соответствия спецификации, затем оптимизируйте на основе вашей стратегии:

1. Сохраняйте транспорты в точности так, как они были получены при регистрации.
2. Определите вашу общую стратегию (максимальная гибкость или адаптация для потребителей).
3. Если выбрали адаптацию для потребителей: внедрите схему с предварительным вводом идентификатора и оптимизируйте транспорты.
4. Обрабатывайте пустые массивы iOS в соответствии с выбранной стратегией.
5. Тщательно тестируйте на веб-платформах, в нативных приложениях iOS и Android.

Ландшафт WebAuthn продолжает развиваться. Производители платформ регулярно обновляют свои реализации, а спецификации, такие как WebAuthn Level 3, вводят новые возможности. Создание гибких систем, в которых обработка транспортов соответствует вашей общей стратегии аутентификации, гарантирует, что ваше внедрение Passkeys останется надежным и будет обеспечивать отличный пользовательский опыт по мере взросления экосистемы.