Узнайте о first‑party и third‑party passkey‑провайдерах, passkey authentication провайдерах и роли AAGUID в управлении passkey на Android, iOS и Web.

Vincent
Created: December 17, 2025
Updated: December 18, 2025

See the original blog version in English here.

Looking for a developer-focused passkey reference? Download our Passkeys Cheat Sheet (incl. WebAuthn ceremonies, objects & Conditional UI). Trusted by dev teams at Ally, Stanford CS & more.
Get Cheat SheetКогда мы используем passkey или занимаемся их внедрением, один компонент становится особенно важным: passkey-провайдер (поставщик ключей доступа). Однако, несмотря на то, что это ключевая часть экосистемы passkey, многие имеют лишь поверхностное представление о провайдерах или не видят разницы между first-party passkey-провайдерами (собственными), third-party passkey-провайдерами (сторонними) и провайдерами аутентификации passkey.
В этой статье мы постараемся пролить свет на эту тему. Будь вы разработчик программного обеспечения, продакт-менеджер или просто интересуетесь новинками веб-безопасности, понимание роли и типов passkey-провайдеров крайне важно. Разложив всё по полочкам, мы хотим дать вам знания для уверенной работы с passkey.
Passkey-провайдер играет фундаментальную роль в экосистеме аутентификации на основе ключей доступа, выступая мостом между устройствами пользователей и безопасным, бесшовным доступом к relying parties (онлайн-сервисам). Но что именно представляет собой passkey-провайдер, особенно учитывая отсутствие официального определения и наличие разных трактовок в сети?
Следующее определение отражает наше понимание и не претендует на то, чтобы быть единственно верным.
По сути, passkey-провайдер — это любая сущность, которая позволяет создавать passkey, управлять ими и использовать их. В ходе нашего исследования мы выделили две основные категории: first- / third-party passkey-провайдеры и провайдеры аутентификации passkey.
В эту категорию входят сущности, способные генерировать passkey на стороне клиента (на устройстве пользователя). Когда passkey создается через такие платформы, он управляется и надежно хранится — часто в облаке производителя операционной системы (например, iCloud Keychain, Google Password Manager) или в стороннем менеджере паролей (например, KeePassXC, 1Password, Dashlane , подробнее см. ниже).
Операционные системы, которые поддерживают нативное создание passkey и управление ими, считаются first-party passkey-провайдерами (собственными провайдерами). В отличие от них, сторонние менеджеры паролей, которые интегрируются с платформой через API, называются third-party passkey-провайдерами (сторонними провайдерами).
У одного first-party или third-party провайдера обычно есть одинаковые идентификаторы Authenticator Attestation Globally Unique Identifiers (AAGUIDs), которые помогают улучшить пользовательский опыт (например, в настройках аккаунта проще различать passkey). Иногда у них может быть несколько AAGUID, но все они принадлежат одному и тому же first-party или third-party провайдеру.
Passkey-провайдеры на устройстве с iOS 17.4
Passkey-провайдеры на устройстве с Android 14
Credential Manager API на Android
Вторая категория охватывает провайдеров аутентификации, которых разработчики могут интегрировать в свои приложения для обработки всех аспектов управления passkey. То есть, это провайдеры, работающие больше на стороне сервера (в отличие от клиентской стороны, описанной выше). Это определение также включает решения вроде Corbado, которые предлагают веб-сайтам и приложениям готовые решения для аутентификации, ориентированные на passkey. Следовательно, таких провайдеров точнее называть провайдерами аутентификации passkey (passkey authentication providers), чтобы отличать их от упомянутых выше first-party и third-party passkey-провайдеров.
В следующих разделах этой статьи мы будем использовать термин "passkey-провайдеры" для обозначения first-party и third-party passkey-провайдеров в соответствии с нашим определением.
По мере того как пользователи начинают применять passkey для различных relying parties, эффективное управление ими становится серьезной задачей. Это особенно актуально для тех, кто использует несколько passkey для одного аккаунта, так как relying party может быть сложно различить эти ключи для редактирования или удаления. Несмотря на удобство и безопасность passkey, возникает потенциальная проблема, если пользователь потеряет один из своих ключей. К счастью, он все еще сможет получить доступ к своему аккаунту на relying party, используя альтернативные passkey. Чтобы помочь пользователям идентифицировать конкретные passkey, некоторые ресурсы предлагают добавлять метаданные, такие как дата создания и последнего использования, в настройках аккаунта. Кроме того, рекомендуется использовать user agents или client hints для автоматического именования и категоризации passkey при их создании. Однако нативные приложения Android или iOS, а также third-party passkey-провайдеры могут не использовать user agents или не добавлять информацию о том, что passkey был сгенерирован сторонним провайдером. Это ограничение подчеркивает необходимость улучшения методов управления passkey, независимо от платформы или провайдера.
Взято из спецификации WebAuthn от W3C
Чтобы облегчить управление passkey, разработчики могут использовать Authenticator Attestation Globally Unique Identifier (AAGUID). AAGUID — это уникальный идентификатор, присваиваемый модели аутентификатора, а не его конкретному экземпляру. Он встроен в данные аутентификатора внутри public key credential, что дает возможность relying parties идентифицировать passkey-провайдера. Эта возможность критически важна, так как помогает пользователям и сервисам ориентироваться в ландшафте passkey, гарантируя, что каждый ключ может быть точно соотнесен с источником его создания.
Например, если passkey создан с помощью Google Password Manager на устройстве Android, relying party может получить AAGUID, специфичный для Google Password Manager. Ссылаясь на этот AAGUID, relying party может пометить passkey соответствующим образом, упрощая управление и идентификацию для пользователя. Более того, relying parties могут предотвратить создание нескольких passkey для одного и того же провайдера, используя серверную опцию WebAuthn excludeCredentials. Это дополнительно улучшает UX, так как у каждого passkey-провайдера будет только один passkey, что избавит пользователя от путаницы.
{ "attestation": "none", "authenticatorSelection": { "residentKey": "preferred", "userVerification": "preferred" }, "challenge": "6V61d0VM5bNTPxWSsrv7YKz0o4awe0ryoDh1V44RPRn6-mBQwv98BTRws6nMrBhEggGn7-tk1bl3YNSwc0oZpA", "excludeCredentials": [ { "id": "1kBn2dmhv5JhuFxqeco1khCBCUBLlWYqZmFtdDujH5pM", "transports": ["internal"], "type": "public-key" } ], "extensions": { "credProps": true }, "pubKeyCredParams": [ { "alg": -7, "type": "public-key" }, { "alg": -257, "type": "public-key" } ], "rp": { "id": "Passkey Demo", "name": "passkeys.eu" }, "user": { "displayName": "Test Name", "id": "ZG1sdVkyVnxe3SFJsYzNR", "name": "Test Name" } }
Чтобы определить passkey-провайдера с помощью AAGUID, relying parties могут обратиться к репозиторию AAGUID, поддерживаемому сообществом. Этот репозиторий предоставляет необходимые сопоставления для идентификации провайдера по имени и, возможно, по иконке, помогая создать более интуитивный интерфейс для управления ключами. Однако важно отметить, что некоторые провайдеры могут намеренно использовать общий AAGUID ("00000000-0000-0000-0000-0000000000000"), обозначающий неизвестного или универсального провайдера.
Получить AAGUID довольно просто с помощью большинства библиотек WebAuthn. Например, при использовании SimpleWebAuthn на стороне сервера, разработчики могут извлечь AAGUID из регистрационной информации, чтобы сопоставить его с известным провайдером, облегчая пользователю управление своими ключами (пример взят из статьи Google "Determine the passkey provider with AAGUID").
// Import a list of AAGUIDs from a JSON file import aaguids from "./aaguids.json" with { type: "json" }; // ... // Use SimpleWebAuthn handy function to verify the registration request. const { verified, registrationInfo } = await verifyRegistrationResponse({ response: credential, expectedChallenge, expectedOrigin, expectedRPID, requireUserVerification: false, }); // ... const { aaguid } = registrationInfo; const provider_name = aaguids[aaguid]?.name || "Unknown";
Хотя AAGUID и является мощным инструментом для управления passkey, использовать его следует с осторожностью. Целостность AAGUID зависит от процесса аттестации, который подтверждает подлинность passkey-провайдера. Без валидной подписи аттестации AAGUID потенциально могут быть подделаны. Стоит отметить, что по состоянию на март 2024 года passkey на некоторых платформах не поддерживают аттестацию, что требует внимательного подхода к их использованию.
Ниже приведен неполный список first-party и third-party passkey-провайдеров для приложений Android, iOS и веб-приложений, использующих наиболее распространенные версии операционных систем и браузеров:
Далее вы найдете примеры всплывающих окон некоторых third-party passkey-провайдеров для создания или сохранения passkey:
Полный анализ 1Password смотрите здесь.
Полный анализ Dashlane смотрите здесь.
Полный анализ KeePassXC смотрите здесь.
Центральное место в развертывании и управлении passkey занимают passkey-провайдеры — сущности, которые не только облегчают создание и управление ключами доступа, но и обеспечивают их бесшовную интеграцию на различных платформах и устройствах.
Целью этой статьи было помочь вам разобраться в том, что такое passkey-провайдер, понять разницу между first-party и third-party провайдерами, а также осознать критическую роль AAGUID (Authenticator Attestation Globally Unique Identifier). Использование AAGUID, как мы выяснили, предлагает перспективное решение для более простой идентификации и управления passkey.
Кроме того, мы проанализировали существующие на данный момент first-party и third-party решения для Android, iOS и Windows, что поможет пользователям выбрать подходящего стороннего провайдера или предпочтительное устройство.
Для разработчиков и продакт-менеджеров понимание работы passkey-провайдеров не только направляет техническую реализацию аутентификации, но и соответствует более широкой цели — улучшению пользовательского опыта и безопасности.
Related Articles
Table of Contents