---
url: 'https://www.corbado.com/ru/blog/webauthn-transporty-vnutrenniy-gibridniy'
title: 'Транспорты WebAuthn: внутренний и гибридный'
description: 'Узнайте, как транспорты WebAuthn работают в API браузеров, iOS AuthenticationServices и Android Credential Manager для кросс-девайсной аутентификации с помощью Passkeys.'
lang: 'ru'
author: 'Vincent Delitz'
date: '2025-10-31T14:40:05.637Z'
lastModified: '2026-03-25T10:07:15.620Z'
keywords: 'транспорты webauthn, webauthn, аутентификация'
category: 'Passkeys Implementation'
---

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

### Обработка транспортов на платформах: краткий справочник

| Платформа                           | Платформенные аутентификаторы                                                                                                       | Аппаратные ключи безопасности |
| ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- |
| **Веб-браузеры**                    | Windows Hello: `["internal"]`<br />Google Password Manager: `["internal", "hybrid"]`<br />iCloud Keychain: `["internal", "hybrid"]` | `["usb", "nfc"]`              |
| **Нативные приложения для Android** | `["internal", "hybrid"]`                                                                                                            | `["usb", "nfc"]`              |
| **Нативные приложения для iOS**     | ⚠️ **Пустой `[]`** (iCloud Keychain)                                                                                                | `["usb", "nfc"]`              |

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

## 1. Введение: транспорты WebAuthn для кросс-девайсной аутентификации

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

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

Ответ кроется в понимании **транспортов WebAuthn** — технической детали, которая
определяет, как аутентификаторы взаимодействуют с доверяющими сторонами. Хотя в теории
транспорты кажутся простыми, их реализация значительно различается в веб-браузерах,
нативных приложениях [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) и
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android), особенно в части обработки `internal` и
`hybrid` транспортов.

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

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

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

## 2. Понимание транспортов WebAuthn: `internal`, `hybrid` и платформенные аутентификаторы

### 2.1 Типы транспортов WebAuthn: `internal`, `hybrid`, `usb`, `nfc`, `ble` и `smart-card`

Транспорты WebAuthn определяют методы связи между аутентификаторами и клиентскими
устройствами.
[Спецификация WebAuthn Level 3](https://www.w3.org/TR/webauthn-3/#enum-transport)
определяет шесть типов транспортов:

**`usb`**: Используется аппаратными ключами безопасности, которые подключаются через
USB-порты, например, YubiKeys или другие токены [FIDO2](https://www.corbado.com/glossary/fido2).

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

**`ble`**: Обеспечивает аутентификацию через Bluetooth Low [Energy](https://www.corbado.com/passkeys-for-energy),
позволяя беспроводную связь с внешними аутентификаторами.

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

**`hybrid`**: Позволяет выполнять кросс-девайсную аутентификацию, обычно когда
пользователь сканирует QR-код для аутентификации на разных устройствах, например,
используя телефон для входа в браузере на компьютере или наоборот. Этот транспорт может
вызывать отображение QR-кода как на настольных, так и на мобильных устройствах, что не
всегда желательно в зависимости от контекста. Примечание: `hybrid` был добавлен в
[WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn).

**`internal`**: Аутентификатор встроен в само устройство — например,
[iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain) (проверка через
[Face ID](https://www.corbado.com/faq/is-face-id-passkey) или Touch ID) на iPhone,
[Windows Hello](https://www.corbado.com/glossary/windows-hello) на ПК или Google
[Password Manager](https://www.corbado.com/blog/passkeys-vs-password-managers) на устройствах
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android). Это платформенные аутентификаторы.

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

### 2.2 Поведение на разных платформах

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

#### 2.2.1 Веб-браузеры

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

**Платформенные аутентификаторы**: [Windows Hello](https://www.corbado.com/glossary/windows-hello) предоставляет
только `["internal"]`, что отражает его привязку к устройству. Однако, когда Chrome
использует [Google Password](https://www.corbado.com/blog/how-to-use-google-password-manager) Manager в качестве
аутентификатора, он предоставляет `["internal", "hybrid"]`, поскольку
[Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) поддерживает
кросс-девайсную аутентификацию через телефоны
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android).

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

**Менеджеры учетных данных с облачной синхронизацией**:
[iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain) в Safari и Google
[Password Manager](https://www.corbado.com/blog/passkeys-vs-password-managers) в Chrome обычно предоставляют
`["internal", "hybrid"]` для поддержки как локальной, так и кросс-девайсной
аутентификации.

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

**Документация**:
[Спецификация W3C WebAuthn](https://w3c.github.io/webauthn/#sctn-issuing-cred-request-to-authenticator)

#### 2.2.2 Нативные приложения для Android

[API Credential Manager](https://developer.android.com/identity/sign-in/credential-manager)
в Android ведет себя аналогично веб-браузерам. При создании Passkeys в нативных
приложениях Android Credential Manager предоставляет информацию о транспортах, которая
отражает поведение в вебе — платформенные аутентификаторы точно сообщают о своих
возможностях, и система последовательно обрабатывает данные о транспортах. Разработчики
Android могут полагаться на эту информацию без специальной обработки.

**Документация**:
[Android Credential Manager](https://developer.android.com/training/sign-in/passkeys)

#### 2.2.3 Нативные приложения для iOS

Ситуация с [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) сложнее. Фреймворк
[AuthenticationServices](https://developer.apple.com/documentation/authenticationservices)
от Apple обрабатывает транспорты по-разному в зависимости от типа аутентификатора:

**Платформенные аутентификаторы** (iCloud Keychain, проверка через
[Face ID](https://www.corbado.com/faq/is-face-id-passkey) или Touch ID): Часто возвращают **пустые массивы
транспортов** во время создания Passkey. Это не означает, что у Passkey нет транспортных
возможностей — это просто значит, что [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) не сообщает
о них явно. Согласно стандарту WebAuthn, отсутствие транспортов означает, что любой
транспорт приемлем, поэтому гибридная аутентификация все равно будет работать.

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

**Документация**:
[Apple AuthenticationServices](https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys)

## 3. Два подхода к обработке транспортов WebAuthn

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

### 3.1 Подход, соответствующий спецификации: доверять `internal` и `hybrid` транспортам

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

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

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

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

- **Соответствие спецификации**: Точно следует стандартам WebAuthn, обеспечивая
  совместимость с будущими обновлениями платформ.
- **Надежность аппаратных ключей**: Отлично работает с аппаратными ключами безопасности
  (YubiKeys и т.д.), которые всегда предоставляют точную информацию о транспортах.
- **Предотвращает недействительные опции**: Позволяет избежать предложения методов
  аутентификации, которые действительно не поддерживаются, например, не будет вызывать
  QR-коды для учетных данных [Windows Hello](https://www.corbado.com/glossary/windows-hello).

**Недостатки**:

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

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

### 3.2 Подход с оптимизацией транспортов: управление `internal` и `hybrid` для кросс-девайсной аутентификации

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

#### 3.2.1 Сценарий 1: Убрать опции аппаратных ключей для ключей iOS

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

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

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

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

#### 3.2.2 Сценарий 2: Предотвратить появление QR-кодов на мобильных устройствах

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

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

```typescript
// При формировании 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` может помешать законным сценариям кросс-девайсной аутентификации, когда
пользователю нужно аутентифицироваться с чужого устройства. Всегда предоставляйте
резервные методы аутентификации и тщательно тестируйте на всех целевых платформах перед
развертыванием оптимизаций транспортов.

#### 3.2.3 Важные соображения

**Это лишь намеки на оптимизацию**: WebAuthn предоставляет другие механизмы для
оптимизации UX аутентификации помимо манипулирования транспортами, такие как
[подсказки (hints)](https://www.w3.org/TR/webauthn-3/#enum-hints).

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

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

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

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

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

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

**Недостатки**:

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

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

### 3.3 Стратегия транспортов WebAuthn: платформенные аутентификаторы и кросс-девайсная аутентификация

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

#### 3.3.1 Стратегия 1: Максимальное соответствие стандарту и свобода пользователя

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

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

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

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

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

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

#### 3.3.2 Стратегия 2: Платформенные аутентификаторы, адаптированные для потребителей

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

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

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

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

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

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

#### 3.3.3 Сравнительная таблица

| Характеристика                | Соответствие стандарту                     | Адаптация для потребителей                               |
| ----------------------------- | ------------------------------------------ | -------------------------------------------------------- |
| **allowCredentials**          | Пустой массив                              | Учетные данные конкретного пользователя                  |
| **Типы аутентификаторов**     | Все (платформенные, аппаратные ключи, CDA) | Платформенные + CDA                                      |
| **API нативных приложений**   | Стандартный WebAuthn                       | Можно использовать preferImmediatelyAvailableCredentials |
| **Аппаратные ключи**          | Поддерживаются                             | Обычно исключены                                         |
| **Важность транспортов**      | Низкая (пустой allow list)                 | Высокая (конкретные учетные данные)                      |
| **QR-коды на мобильных**      | Могут появляться                           | Можно оптимизировать и убрать                            |
| **Пользовательский опыт**     | Больше опций, больше сложности             | Оптимизированный, меньше решений                         |
| **Сложность реализации**      | Ниже                                       | Выше                                                     |
| **Трудности для потребителя** | Выше (несколько вариантов аутентификации)  | Ниже (оптимизировано для потребительских сценариев)      |

#### 3.3.4 Схемы с предварительным вводом идентификатора и перечисление учетных записей

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

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

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

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

## 4. Лучшие практики реализации транспортов WebAuthn

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

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

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

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

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

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

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

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

## 5. Заключение: выбор вашей стратегии транспортов WebAuthn

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

### 5.1 Ключевые выводы

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

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

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

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

### 5.2 Выбор вашей стратегии

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

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

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

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

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

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

### 5.3 Рекомендация по реализации

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

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

Ландшафт WebAuthn продолжает развиваться. Производители платформ регулярно обновляют свои
реализации, а спецификации, такие как [WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn),
вводят новые возможности. Создание гибких систем, в которых обработка транспортов
соответствует вашей общей стратегии аутентификации, гарантирует, что ваше внедрение
Passkeys останется надежным и будет обеспечивать отличный пользовательский опыт по мере
взросления экосистемы.