Идентификатор проверяющей стороны WebAuthn (rpID) и ключи доступа: домены и нативные приложения

Аутентификация с помощью ключей доступа (passkeys) быстро становится нормой по мере того, как технологические гиганты, такие как TikTok, GitHub, WhatsApp, X (Twitter), LinkedIn и Amazon, внедряют их или уже сделали это. Очевидно, что технологический мир признает важность простой и безопасной аутентификации.

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

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

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

Фишинговая атака — это атака, при которой жертву обманом заставляют предоставить учетные данные поддельному сайту, имитирующему оригинальный. Например, представьте, что вы получаете электронное письмо, похожее на сообщение от вашего банка, с просьбой войти в систему. Вы нажимаете на ссылку, и веб-сайт выглядит легитимным, поэтому вы вводите свои учетные данные, и злоумышленник может использовать их для входа на исходный сайт. Это становится все более серьезной проблемой в цифровую эпоху, и даже крупные компании, такие как Okta (провайдер аутентификации!) или Retool , стали жертвами целевых фишинговых атак (spear-phishing — особая форма фишинга, при которой на конкретных жертв направлены узкоспециализированные фишинговые уловки), что подчеркивает необходимость надежных мер безопасности.

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

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

Во время процедуры регистрации (sign-up) создается новый ключ доступа для онлайн-сервиса (проверяющей стороны) через веб- или нативное приложение. В ходе этого процесса домен (Relying Party ID), для которого создается ключ доступа, сохраняется в самом ключе.

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

Далее мы подробно рассмотрим, как работает этот процесс сопоставления доменов и как, в частности, защищаются нативные приложения.

Идентификатор проверяющей стороны (Relying Party ID) — это, по сути, домен, хранящийся в ключе доступа и гарантирующий, что ключ доступа будет работать только в том случае, если текущий URL-адрес браузера (источник пользователя, который автоматически отправляется с каждым запросом) совпадает с ним (см. подход с нативными приложениями ниже). Это важнейший компонент спецификации WebAuthn, с которой вы можете ознакомиться здесь. Идентификатором проверяющей стороны может быть корневой домен (например, corbado.com) или поддомен (auth.corbado.com). Вы не можете сохранить корневой домен в качестве Relying Party ID, если он находится в Списке публичных суффиксов (найдите список и библиотеки для определения публичных суффиксов здесь). Изменение Relying Party ID для онлайн-сервиса приведет к нарушению работы существующих ключей доступа (исключения: новый Relying Party ID является поддоменом старого Relying Party ID, или настроены запросы связанных источников через .well-known/webauthn, чтобы разрешить повторное использование ключей доступа между связанными доменами).

В процессе аутентификации Relying Party ID сверяется с URL-адресом браузера (источником пользователя), чтобы убедиться в их совпадении. Совпадение в этом смысле означает, что либо:

• URL-адрес браузера (источник пользователя) точно совпадает с Relying Party ID, ИЛИ
• URL-адрес браузера (источник пользователя) является поддоменом, соответствующим Relying Party ID, а родительский домен доступен для регистрации (например, com или любой домен из Списка публичных суффиксов не подойдут).

Вот подробная схема того, какой originalHost (второй столбец) имеет доступ к своему родительскому домену:

Ниже вы видите проанализированные параметры PublicKeyCredentialCreationOptions:

{
    "publicKey": {
        "attestation": "direct",
        "authenticatorSelection": {
            "authenticatorAttachment": "platform",
            "requireResidentKey": false,
            "userVerification": "preferred"
        },
        "challenge": "qNqrdXUrk5S7dCM1MAYH3qSVDXznb-6prQoGqiACR10=",
        "excludeCredentials": [],
        "pubKeyCredParams": [
            {
                "alg": -7,
                "type": "public-key"
            }
        ],
        "rp": {
            "id": "corbado.com",
            "name": "Corbado"
        },
        "timeout": 30000,
        "user": {
            "displayName": "Corbado user",
            "id": "bz9ZDfHzOBLycqISTAdWwWIZt8VO-6mT3hBNXS5jwmY="
        }
    }
}

rp означает Relying Party (проверяющая сторона).

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

1. Злоумышленник разрабатывает клон PayPal — поддельный веб-сайт, который пытается украсть ваши учетные данные PayPal, чтобы войти в систему от вашего имени и перевести деньги на счет злоумышленника. Этот поддельный сайт PayPal размещен на домене paybal.com (поэтому на первый взгляд часто не видно, что это другой домен).
2. Ранее вы уже создали ключ доступа для легитимного сайта PayPal. В этом ключе доступа был сохранен Relying Party ID paypal.com.
3. Вы заходите на поддельный сайт PayPal по адресу paybal.com (поскольку вы посещаете этот сайт, источником вашего запроса является paybal.com*), и сайт отправляет вашему устройству (аутентификатору) запрос (challenge) для Relying Party ID paypal.com (здесь он пытается вас обмануть) и просит подписать его вашим ключом доступа для Relying Party ID paypal.com.
4. Ваше устройство (аутентификатор) проверяет, совпадают ли источник запроса (paybal.com) и Relying Party ID, сохраненный в ключе доступа (paypal.com).
5. Поскольку они очевидно не совпадают, аутентификация завершается ошибкой, что спасает вас от предоставления злоумышленнику доступа к вашему аккаунту PayPal.

Следующая диаграмма иллюстрирует этот механизм предотвращения фишинга.

В случае нативного приложения обработка источника (origin) зависит от платформы: На Android источник имеет формат android:apk-key-hash:<SHA256_fingerprint>. На iOS источником WebAuthn является веб-источник RP (например, https://paypal.com). В обоих случаях доверие между вашим нативным приложением и сервером проверяется через соответствующий файл ассоциации (см. ниже). Подробную информацию о том, как работает проверка источника для нативных приложений, смотрите в нашем специальном руководстве по проверке источников WebAuthn для нативных приложений.

Присоединяйтесь к нашему Passkeys Community для обновлений и поддержки.

Присоединиться

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

Использование WebView* для интеграции ключей доступа означает встраивание веб-браузера в нативное приложение для управления процессом аутентификации. Этот подход, по сути, отображает веб-страницу внутри приложения, что упрощает повторное использование веб-потоков аутентификации без необходимости их переписывания для нативной платформы. Однако есть и некоторые недостатки. WebView может не поддерживать все функции ключей доступа, и существует потенциальный риск атак вида «человек посередине», если интеграция реализована небезопасно. Кроме того, пользовательский опыт может быть не таким плавным, как при нативной интеграции, и могут возникнуть сложности с поддержанием единообразного поведения на разных устройствах и версиях ОС.

*Существует несколько типов WebView: на iOS (WKWebView, SFSafariViewController или SFAuthenticationSession / ASWebAuthenticationSession для потоков аутентификации на основе OAuth/OpenID Connect) и Android (WebView, CCT-Chrome Custom Tabs). Подробности смотрите в этой статье. Мы рекомендуем использовать SFSafariViewController/ASWebAuthenticationSession и Chrome Custom Tabs в контексте ключей доступа, если вы не хотите использовать нативную интеграцию.

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

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

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

В дальнейшем мы сосредоточимся на нативной интеграции ключей доступа.

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

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

Нативные приложения (например, приложения для iOS или Android) представляют собой более сложную задачу по сравнению с веб-приложениями. В отличие от веб-приложений, здесь нет URL-адреса браузера для сопоставления с идентификатором проверяющей стороны. Тем не менее, для обеспечения того же уровня безопасности домены связываются с нативными приложениями с помощью файлов ассоциации, чтобы установить доверие между доменом и нативным приложением.

Это особенно важно, если ключ доступа был создан в веб-приложении и должен использоваться для того же Relying Party ID в нативном приложении (и наоборот).

iOS использует файл apple-app-site-association. Этот файл содержит различные права (entitlements), но для WebAuthn и ключей доступа важно право webcredentials.

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

Получить шпаргалку

{
    "webcredentials": {
        "apps": ["9RF9KY88B2.com.corbado.passkeys"]
    }
}

В webcredentials.apps вам нужно указать префикс идентификатора приложения (Application Identifier Prefix, например 9RF9KY77B2) и идентификатор бандла (Bundle Identifier, например com.corbado.passkeys).

Чтобы нативные приложения iOS работали, файл apple-app-site-association должен храниться в каталоге /.well-known идентификатора проверяющей стороны (https://<Relying Party ID>/.well-known/apple-app-site-association).

Посмотрите рабочий пример здесь.

Android использует файл assetlinks.json, который, как и его аналог в iOS, требует особых настроек для WebAuthn и ключей доступа.

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.corbado.passkeys.pub",
            "sha256_cert_fingerprints": [
                "F8:90:4E:9A:99:01:71:75:25:38:D5:36:16:2D:B3:65:EB:41:51:D4:53:9A:72:BC:4B:56:C5:16:43:62:E2:C0"
            ]
        }
    }
]

У вас должны быть заданы значения relation: delegate_permission/common.handle_all_urls и delegate_permission/common.get_login_creds. Кроме того, вам нужно добавить имя пакета и отпечаток SHA-256 вашего сертификата подписи.

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

Посмотрите рабочий пример здесь.

Чтобы приложения Android работали, файл assetlinks.json должен храниться в каталоге /.well-known идентификатора проверяющей стороны (https://<Relying Party ID>/.well-known/assetlinks.json - то есть примерно так же, как в iOS).

Ознакомьтесь с этой статьей в блоге, чтобы увидеть пример реализации, которая разделяет ключи доступа между нативным приложением для Android/iOS и веб-приложением.

Экспериментируйте с passkey-флоу в Passkeys Debugger.

Попробовать бесплатно

Процесс установления доверия между приложением iOS и веб-приложением выглядит следующим образом:

1. Разработчик приложения для iOS должен указать список доменов, которые он хочет ассоциировать с нативным приложением. Эти домены жестко прописываются в правах (entitlements) приложения iOS, например:

• webcredentials:auth.Corbado.com
• webcredentials:*.Corbado.com

2. Каждый раз, когда приложение iOS устанавливается или обновляется, iOS загружает файл apple-app-site-association для каждой записи из списка прав приложения.

3. Когда учетные данные (например, ключ доступа) создаются внутри приложения iOS, приложение проверяет, ассоциирован ли домен сервера проверяющей стороны с приложением, проверяя следующие два аспекта:

• Существует ли на устройстве файл apple-app-site-association для этого домена сервера проверяющей стороны?
• Указано ли приложение iOS в этом файле apple-app-site-association?

Если и только если на оба вопроса можно ответить «да», в приложении iOS может быть создан ключ доступа.

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

Процесс установления доверия между приложением Android и веб-приложением выглядит следующим образом:

1. Разработчик приложения для Android должен указать список доменов, которые он хочет связать с приложением. Эти домены хранятся в качестве целевых (targets) с пространством имен web в файле assetlinks.json. Чтобы объявить, что приложения Android и веб-приложения делятся учетными данными, необходимо указать delegate_permission/common.get_login_creds. Подробности можно найти здесь.

2. Если ключ доступа создается внутри приложения Android, приложение проверяет, связан ли Relying Party ID с приложением, просматривая файл assetlinks.json:

• Существует ли файл assetlinks.json для этого Relying Party ID по адресу https://<Relying Party ID>./well-known/assetlinks.json
• Правильно ли приложение Android определено в качестве цели.

3. Если и только если на оба вопроса можно ответить «да», в приложении Android может быть создан ключ доступа.

Диаграмма ниже сравнивает эти процессы установления доверия бок о бок.

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

Подписаться

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

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

• Для Android: flutter_deeplinking_enabled в AndroidManifest.xml
• Для iOS: FlutterDeepLinkingEnabled true в Info.plist

Поскольку мы на собственном опыте убедились, что работа с Relying Party ID, различными уровнями (под)доменов и CNAME может быть весьма сложной задачей, мы представляем четыре различных примера и объясняем, почему и как они работают.

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

В этом примере файл apple-app-site-association / assetlinks.json для Corbado.com может быть загружен без проблем при установке / обновлении нативного приложения, поскольку файл находится в том же месте, что и Relying Party ID.

Ключ доступа для Relying Party ID может быть создан.

В этом примере файл apple-app-site-association / assetlinks.json для auth.corbado.com может быть загружен без проблем при установке / обновлении нативного приложения, так как файл находится в расположении Relying Party ID, поскольку CNAME указывает с Relying Party ID на сохраненное расположение.

Ключ доступа для Relying Party ID может быть создан.

В этом примере файл apple-app-site-association / assetlinks.json для auth.corbado.com может быть загружен без проблем при установке / обновлении нативного приложения, поскольку файл, благодаря CNAME, находится там, где auth.corbado.com его ожидает.

НО: Файл apple-site-association-file / assetlinks.json для corbado.com не может быть загружен при установке / обновлении нативного приложения, поскольку файл не находится по адресу https://corbado.com/.well-known/apple-app-site-association / https://corbado.com/.well-known/assetlinks.json, где он ожидается, и на него не указывает CNAME.

Ключ доступа для Relying Party ID не может быть создан.

В этом примере файл apple-app-site-association для corbado.com может быть загружен без проблем при установке / обновлении нативного приложения, поскольку файл находится там, где ожидается, и право webcredentials (*.corbado.com) соответствует Relying Party ID (auth.corbado.com). Обратите внимание, что этот пример не работает для Android, так как Android не работает с такими (подстановочными) правами. В целом этот способ определения Relying Party ID не рекомендуется.

Ключ доступа для Relying Party ID может быть создан.

Присоединяйтесь к нашему Passkeys Community для обновлений и поддержки.

Присоединиться

Ошибка:

Вы начали разработку и определили поддомен (например, login.acme.com) в качестве Relying Party ID. Первые пользователи создали ключи доступа для этого Relying Party ID. Затем вы замечаете, что эти ключи доступа также нужны для аутентификации на другом поддомене (например, app.acme.com). Поскольку источник пользователя и Relying Party ID для нового поддомена не совпадают, пользователь не может войти с помощью ключа доступа. Изменение Relying Party ID в настройках WebAuthn на acme.com сделает недействительными все существующие ключи доступа, поскольку новый источник и Relying Party ID, сохраненные в существующих ключах доступа, не совпадают.

Решение:

Дважды проверьте всё на этапе определения Relying Party ID, так как это более-менее окончательное решение. Если вы сомневаетесь и хотите быть готовыми к будущему, то есть, возможно, другим поддоменам в будущем понадобится ключ доступа для аутентификации, мы рекомендуем использовать корневой домен (например, acme.com) в качестве Relying Party ID, если он не включен в Список публичных суффиксов.

Ошибка:

Вы разрабатываете нативное и веб-приложение одновременно. Чтобы ускорить процесс, вы используете два разных сервера WebAuthn (с разными Relying Party ID для нативного и веб-приложения). Когда ваши пользователи создают первые ключи доступа, соответствующий Relying Party ID сохраняется в ключе доступа. Разрешить вход на разных устройствах / платформах с одним и тем же ключом доступа, например, с ключом доступа, созданным в веб-приложении, при попытке войти в нативное приложение, больше не получится. Объединение двух серверов WebAuthn приведет к отказу от ключей доступа, зарегистрированных на старом сервере WebAuthn (старом Relying Party ID), и ваши пользователи не смогут входить с помощью этих ключей доступа.

Решение:

Если у вас несколько приложений (например, веб-приложение и нативное приложение), всегда используйте только один сервер WebAuthn и определяйте только один Relying Party ID для всех ваших приложений. Связывание этих приложений можно выполнить с помощью шагов, описанных выше.

Ошибка:

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

Решение:

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

Ошибка:

Вы развернули файл apple-app-site-association на своем сервере и хотите сразу же начать создавать ключ доступа на тестовом устройстве. По какой-то причине вы не можете создать ключ доступа и получаете сообщения об ошибках.

Решение:

Причина этих сообщений об ошибках заключается в том, что устройства iOS загружают файл apple-app-site-association для проверки проверяющей стороны (Relying Party). При этом устройства iOS не отправляют прямой запрос на ваш сервер, а используют CDN. И устройство, и CDN кэшируют файл apple-app-site-association после его успешного извлечения. Из-за этой функции кэширования новые изменения в вашем файле apple-app-site-association не сразу отражаются в вашем приложении. Кэширование файла apple-app-site-association в CDN может занять до 24 часов. Чтобы обойти это ограничение во время разработки, вы можете добавить ?mode=developer к Relying Party ID и полностью отключить кэширование (например, Relying Party ID будет иметь вид acme.com?mode=developer).

Ошибка:

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

Решение:

Версии Android, поддержка Play Store и версии API играют важную роль при тестировании приложения с ключами доступа. Кроме того, вы должны войти в учетную запись Google. Подробности см. в разделе устранения неполадок.

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

Ниже мы приводим очень конкретное дерево решений, которое должно помочь вам определить правильный Relying Party ID и то, как следует обрабатывать / размещать файлы ассоциации при использовании Corbado в качестве решения для ключей доступа.

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

Для среды разработки мы предполагаем, что вы хотите быстро начать разработку и тестирование. Relying Party ID можно будет изменить позже, если вы захотите запустить продукт (go live).

• Установите Relying Party ID = pro-XXX.frontendapi.cloud.corbado.io (значение по умолчанию)
• Corbado размещает файл ассоциации за вас
• Никаких действий с DNS с вашей стороны

Непросто одновременно тестировать и веб-приложение, и нативное приложение

Вариант 1:

Либо вы устанавливаете Relying Party ID = pro-XXX.frontendapi.cloud.corbado.io (работает нативное приложение), ИЛИ устанавливаете Relying Party ID = localhost (работает веб-приложение)

Вариант 2:

Единственное решение, позволяющее одновременно работать нативному и веб-приложению, — использовать локальный обратный прокси-сервер (reverse proxy) (это довольно костыльное решение):

• Установите Relying Party ID = acme-dev.com
• Установите CNAME с acme-dev.com => pro-XXX.frontendapi.cloud.corbado.io
• Добавьте локальную запись в /etc/hosts: localhost acme-dev.com
• Добавьте обратный прокси-сервер (nginx) с правилом для acme-dev.com => localhost:3000 (в качестве примера)

В производственной среде вам нужно решить, устраивает ли вас поддомен в качестве Relying Party ID (например, auth.acme.com) или вы хотите использовать корневой домен в качестве Relying Party ID (например, acme.com).

• Установите Relying Party ID = auth.acme.com
• Corbado размещает файл ассоциации за вас
• Установите CNAME с auth.acme.com => pro-XXX.frontendapi.cloud.corbado.io

• Установите Relying Party ID = auth.acme.com
• Corbado размещает файл ассоциации за вас
• Установите CNAME с auth.acme.com => pro-XXX.frontendapi.cloud.corbado.io (также требуется для работы файлов cookie, если вы используете управление сеансами Corbado)

• Установите Relying Party ID = acme.com
• Разместите файл ассоциации самостоятельно на своем собственном сервере по адресу acme.com/.well-known/<association file>
• Никаких действий с DNS с вашей стороны

• Установите Relying Party ID = acme.com
• Разместите файл ассоциации самостоятельно на своем собственном сервере по адресу acme.com/.well-known/<association file>
• Если вы используете управление сеансами Corbado, вам нужно установить CNAME с auth.acme.com => pro-XXX.frontendapi.cloud.corbado.io, чтобы файлы cookie работали (этот CNAME не нужен для Relying Party ID, исключительно для управления сеансами)

Следующее дерево решений резюмирует все пути конфигурации.

Идентификатор проверяющей стороны (Relying Party ID) является краеугольным камнем WebAuthn и аутентификации на основе ключей доступа, обеспечивающим надежную защиту от фишинга. Крайне важно правильно его настроить, понять тонкости сопоставления доменов и обеспечить корректное развертывание для нативных приложений. В этой статье мы рассказали, как настроить их правильно и как справляться с различными ошибками. Как только конфигурация вашего rpID станет надежной, сосредоточьтесь на оптимизации потоков создания ключей доступа и потоков входа по ключам доступа для стимулирования реального внедрения. Для получения дополнительной информации о настройке ключей доступа для нативных приложений мы рекомендуем прочитать о ключах доступа во Flutter.

Если у вас есть дополнительные вопросы или вам нужна помощь, не стесняйтесь обращаться к нам.

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

Аутентификатор сравнивает фактический источник (origin) браузера с идентификатором проверяющей стороны (Relying Party ID), хранящимся в ключе доступа. Если злоумышленник размещает поддельный сайт на другом домене, несовпадение источников автоматически приводит к сбою аутентификации, даже если в поддельном запросе указан легитимный RP ID. Эта привязка означает, что ключ доступа, зарегистрированный на paypal.com, не может быть использован на похожем домене, таком как paybal.com.

Изменение RP ID делает недействительными все существующие ключи доступа, поскольку сохраненный RP ID в каждой учетной записи больше не будет совпадать с новым значением. Единственным исключением является случай, когда новый RP ID является поддоменом старого или когда настроены запросы связанных источников (Related Origin Requests) через .well-known/webauthn. Чтобы избежать этой необратимой проблемы, с самого начала выбирайте корневой домен в качестве RP ID.

iOS не загружает файл apple-app-site-association напрямую с вашего сервера. Она использует CDN Apple, кэширование недавно развернутого или обновленного файла в которой может занять до 24 часов. Во время разработки добавьте ?mode=developer к идентификатору проверяющей стороны, чтобы полностью обойти кэширование.

Рекомендуется использовать корневой домен (например, acme.com), поскольку ключи доступа, созданные на любом поддомене, могут проходить аутентификацию на всех поддоменах этого корня. RP ID в виде поддомена ограничивает использование ключа доступа этим поддоменом и его дочерними элементами, что в дальнейшем может нарушить потоки между поддоменами. Если у вас несколько корневых доменов, таких как acme.com и acme.co.uk, настройте запросы связанных источников (Related Origin Requests) через .well-known/webauthn, чтобы разрешить повторное использование ключей доступа между ними.