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

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

Получить whitepaper

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

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

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

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

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

В этой статье рассматриваются:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ключевые выводы:

Доминирование платформенных аутентификаторов: подавляющее большинство ключей доступа используют транспорт internal, часто в сочетании с hybrid для поддержки кросс-девайс аутентификации. Это отражает ориентацию потребителей на платформенные аутентификаторы (Связка ключей iCloud, Google Password Manager).

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

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

Существуют варианты порядка: порядок транспортов в массивах (["internal", "hybrid"] по сравнению с ["hybrid", "internal"]) варьируется в зависимости от платформы и реализации аутентификатора, но не несет функциональной разницы — оба указывают на поддержку одних и тех же методов передачи.

Устаревшая терминология: идентификатор транспорта cable иногда появляется в старых реализациях и является синонимом hybrid (caBLE = облачный Bluetooth Low Energy, первоначальное название гибридного транспорта).

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

Доступность транспорта показывает, о чем сообщают аутентификаторы, а не завершится ли результирующий процесс успешно. Анализ завершения кросс-девайс аутентификации в рамках Corbado Passkey Benchmark 2026 оценивает завершение с транспортом hybrid в первом квартале 2026 года на уровне 60–78 % в веб-среде Windows и 66–86 % в веб-среде macOS в целом. При этом показатели разделяются на 79–98 % (Windows) / 83–98 % (macOS) для процессов с запросами на том же устройстве в сравнении с 52–67 % (Windows) / 59–76 % (macOS) для процессов с вводом идентификатора в первую очередь. Рассматривайте hybrid как самый затратный транспорт в логике маршрутизации и отдавайте предпочтение процессам, при которых пользователь остается на устройстве, на котором хранятся учетные данные.

Один и тот же аутентификатор часто сообщает разные шаблоны транспортов в зависимости от платформы, версии и контекста реализации. Это нормально и ожидаемо:

Связка ключей iCloud демонстрирует три шаблона:

• ["internal", "hybrid"] — наиболее распространенный, обычно из веб-браузеров.
• [] (пустой массив) — очень распространенный, из нативных приложений iOS.
• ["hybrid", "internal"] — менее распространенный, вариация порядка.
• только ["internal"] или ["hybrid"] — редкие крайние случаи.

Google Password Manager демонстрирует наибольшие вариации:

• ["hybrid", "internal"] — самый распространенный шаблон.
• ["internal", "hybrid"] — распространенный альтернативный порядок.
• ["internal", "cable"] — старые реализации (cable = старый термин для hybrid).
• [] (пустой массив) — в определенных нативных контекстах.
• Одиночные транспорты встречаются редко.

Windows Hello наиболее последователен:

• ["internal"] — доминирующий шаблон (по дизайну привязан к устройству).

Менеджеры паролей, такие как 1Password, Bitwarden, Dashlane и LastPass, все показывают схожие шаблоны вариаций:

• Порядки как ["internal", "hybrid"], так и ["hybrid", "internal"].
• Пустые массивы [] из контекстов нативных приложений.
• Иногда просто ["internal"].

Samsung Pass (экосистема Android) в основном использует:

• ["hybrid", "internal"] и ["internal", "hybrid"] — оба порядка распространены.

Различия между платформами: один и тот же аутентификатор ведет себя по-разному в вебе и в нативных приложениях, на iOS и на Android, или на Windows и на macOS.

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

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

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

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

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

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

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

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

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

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

Недостатки:

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

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

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

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

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

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

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

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

Решение: удалите транспорт 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).

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

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

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

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

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

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

Недостатки:

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

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

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

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

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

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

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

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

Этот подход оптимизирован для потребительского UX за счет ограничения создания ключей доступа платформенными аутентификаторами и использования процессов с вводом идентификатора в первую очередь (identifier-first).

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

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

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

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

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

• Подсказки и предложения пользователям: подсказки после входа и процессы автоматического создания используют authenticatorAttachment: "platform", направляя пользователей к сразу доступным ключам доступа с высокими показателями успешности.
• Настройки веб-аккаунта: предлагают создание без authenticatorAttachment, позволяя опытным пользователям выбирать ключи безопасности, сторонние менеджеры паролей или любой доступный аутентификатор.

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

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

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

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

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

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

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

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

Изящно обрабатывайте пустые массивы: при получении пустого массива транспортов от платформенных аутентификаторов iOS:

• В соответствии со спецификацией: оставьте пустым или опустите свойство транспортов — указывает, что информация о транспорте недоступна; платформы сами определят доступные параметры.
• Подход с оптимизацией: заполните ["internal", "hybrid"], чтобы контролировать, какие варианты аутентификации будут показаны.

Стратегии транспортов в вебе и в нативных приложениях: различайте обработку транспортов в зависимости от контекста:

• Веб-аутентификация: включайте все транспорты, обеспечивая более широкую поддержку аутентификаторов, включая ключи безопасности через USB/NFC.
• Аутентификация в нативном приложении: используйте preferImmediatelyAvailableCredentials для незаметной аутентификации; транспорты отправляются в сохраненном виде.
• Страницы настроек/управления: поддерживайте все типы аутентификаторов для опытных пользователей.

Обработка аутентификации по ключам безопасности: когда у пользователей зарегистрированы ключи безопасности:

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

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

• Регистрация: веб, нативные приложения iOS, нативные приложения Android.
• Аутентификация: веб, нативные приложения iOS, нативные приложения Android.
• Убедитесь, что тихая аутентификация работает с preferImmediatelyAvailableCredentials.
• Убедитесь, что ключи безопасности работают в процессах настроек без authenticatorAttachment.
• Убедитесь, что QR-коды появляются только в соответствующих контекстах.

Понимайте семантику транспортов: осознайте разницу между пустыми и отсутствующими значениями транспортов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О 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 →

iOS AuthenticationServices скрывает информацию о транспорте для платформенных аутентификаторов, таких как Связка ключей iCloud, возвращая пустые массивы в соответствии с положениями о конфиденциальности спецификации WebAuthn. Ключи безопасности в iOS предоставляют данные о транспорте, такие как ["usb"] или ["nfc"]. Проверяющим сторонам следует рассматривать все транспорты как подсказки, а не как авторитетные гарантии возможностей.

cable — это устаревшая терминология, синоним hybrid, расшифровывающаяся как caBLE (cloud-assisted Bluetooth Low Energy). Оба термина описывают кросс-девайс аутентификацию, например сканирование QR-кода для аутентификации сеанса на настольном компьютере с помощью телефона. hybrid — текущий термин, введенный в WebAuthn Level 3, и его следует использовать в новых реализациях.

Для потребительских приложений, использующих процессы ввода идентификатора в первую очередь, явно задайте для транспортов значение ["hybrid", "internal"] для платформенных аутентификаторов iOS, которые вернули пустые массивы при регистрации. Это предотвратит появление запросов ключей безопасности USB и NFC в пользовательском интерфейсе аутентификации. Альтернативный вариант, соответствующий спецификации, заключается в том, чтобы оставить массивы пустыми или вообще опустить свойство транспортов.

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

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