Провайдеры ключей доступа: Типы, AAGUID и внедрение

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

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

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

Получите бесплатную оценку passkey за 15 минут.

Записаться на бесплатную консультацию

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

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

Следующее определение отражает наше понимание и не претендует на звание единственно точного.

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

Эта категория включает сущности, способные генерировать ключ доступа на стороне клиента (на устройстве пользователя). Когда ключ доступа создается через эти платформы, он безопасно управляется и хранится, часто в облаке производителя операционной системы (например, iCloud Keychain, Google Password Manager) или в стороннем менеджере паролей (например, KeePassXC, 1Password, Dashlane — см. подробнее ниже).

Операционные системы, которые позволяют создавать и управлять ключами доступа нативно, считаются first-party провайдерами ключей доступа. Напротив, сторонние менеджеры паролей, которые интегрируются с платформой через API, называются third-party провайдерами ключей доступа.

Один first-party или third-party провайдер ключей доступа имеет одни и те же Глобально уникальные идентификаторы аттестации аутентификатора (AAGUID), которые помогают улучшить пользовательский опыт (например, в настройках аккаунта, чтобы было легче различать ключи доступа). Иногда они могут иметь несколько AAGUID, которые все принадлежат одному и тому же first- или third-party провайдеру ключей доступа.

Провайдеры ключей доступа на устройстве с iOS 17.4

Провайдеры ключей доступа на устройстве с Android 14

Credential Manager API в Android

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

В следующих разделах этой статьи мы будем использовать термин "провайдеры ключей доступа" для обозначения first-party и third-party провайдеров ключей доступа в соответствии с нашим определением.

По мере того как пользователи начинают использовать ключи доступа для различных проверяющих сторон, эффективное управление ими становится серьезной проблемой. Это также верно для пользователей, которые используют несколько ключей доступа для одного аккаунта, поскольку различение этих ключей доступа для целей редактирования или удаления может быть сложным для проверяющей стороны. Несмотря на удобство и безопасность, которые предлагают ключи доступа, существует потенциальная проблема, если пользователь потеряет один из своих ключей доступа. К счастью, он все еще может получить доступ к своему аккаунту у проверяющей стороны, используя альтернативные ключи доступа. Чтобы помочь пользователям идентифицировать определенные ключи доступа, некоторые ресурсы предлагают использовать метаданные, такие как даты создания и последнего использования ключа доступа в настройках аккаунта. Кроме того, рекомендуется использовать user agents или client hints для автоматического наименования и категоризации ключей доступа при их создании. Однако нативные приложения для Android или iOS, а также third-party провайдеры ключей доступа могут не использовать user agents или не добавлять информацию, указывающую на то, что ключ доступа был сгенерирован сторонним провайдером ключей доступа. Это ограничение подчеркивает необходимость в улучшенных методах помощи пользователям в эффективном управлении их ключами доступа, независимо от платформы или провайдера.

Взято из спецификации WebAuthn W3C

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

Например, если ключ доступа создается с помощью Google Password Manager на устройстве Android, проверяющая сторона может получить AAGUID, специфичный для Google Password Manager. Ссылаясь на этот AAGUID, проверяющая сторона затем может соответствующим образом отметить ключ доступа, упрощая управление и идентификацию для пользователя. Более того, проверяющие стороны могут предотвратить создание нескольких ключей доступа для одного и того же провайдера ключей доступа с помощью опции сервера WebAuthn excludeCredentials. Это еще больше улучшает UX ключей доступа, так как каждый провайдер ключей доступа будет иметь только один ключ доступа, тем самым избегая путаницы у пользователя.

{
    "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"
    }
}

Чтобы определить провайдера ключей доступа с помощью AAGUID, проверяющие стороны могут обратиться к репозиторию AAGUID, созданному сообществом. Этот репозиторий предоставляет необходимые сопоставления для идентификации провайдера ключей доступа по имени и, потенциально, по иконке, помогая обеспечить более интуитивно понятный пользовательский интерфейс для управления ключами доступа. Однако важно отметить, что некоторые провайдеры ключей доступа могут намеренно использовать общий AAGUID ("00000000-0000-0000-0000-0000000000000"), представляющий неизвестного или общего провайдера.

Извлечь AAGUID довольно просто с большинством библиотек WebAuthn. Например, при использовании SimpleWebAuthn на стороне сервера разработчики могут извлечь AAGUID из информации о регистрации, чтобы сопоставить его с известным провайдером, повышая способность пользователя управлять своими ключами доступа с большей легкостью (взято из статьи Google "Определение провайдера ключей доступа по 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 предлагают мощный инструмент для управления ключами доступа, их следует использовать с осторожностью. Целостность AAGUID зависит от процесса аттестации, который подтверждает подлинность провайдера ключей доступа. Без действительной подписи аттестации AAGUID потенциально могут быть подделаны. По состоянию на март 2024 года примечательно, что ключи доступа на некоторых платформах не поддерживают аттестацию, что подчеркивает необходимость тщательного рассмотрения при их использовании.

Далее вы найдете неисчерпывающий список first-party и third-party провайдеров ключей доступа для приложений Android, приложений iOS и веб-приложений с использованием очень распространенных версий операционных систем ключей доступа и браузеров:

Ниже вы найдете несколько всплывающих окон от сторонних (third-party) провайдеров ключей доступа для создания / сохранения ключа доступа:

Смотрите полный анализ 1Password здесь.

Смотрите полный анализ Dashlane здесь.

Смотрите полный анализ KeePassXC здесь.

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

Понимание того, что такое провайдер ключей доступа, включая различие между first-party и third-party провайдерами, а также критической роли Глобально уникального идентификатора аттестации аутентификатора (AAGUID), было целью этой статьи. Использование AAGUID, как обсуждалось, предлагает многообещающее решение, обеспечивающее более простую идентификацию и управление ключами доступа.

Кроме того, мы проанализировали, какие first-party и third-party провайдеры ключей доступа существуют в настоящее время для Android, iOS и Windows, помогая пользователям также найти подходящего third-party провайдера ключей доступа или желаемое устройство.

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

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