패스키 제공자: 다양한 유형, AAGUID 및 도입 현황

Passkeys 치트시트. passkey 프로그램을 위한 실무 가이드, 도입 패턴, KPI.

치트시트 받기

패스키를 사용하거나 패스키 구현 분야에서 일할 때, **패스키 제공자(Passkey Provider)**라는 구성 요소는 매우 중요해집니다. 하지만 패스키 생태계에서 중요한 부분임에도 불구하고, 많은 사람들이 패스키 제공자에 대해 대략적으로만 이해하고 있거나 퍼스트파티 패스키 제공자, 써드파티 패스키 제공자, 그리고 패스키 인증 제공자 간의 차이를 알지 못합니다.

15분 안에 무료 passkey assessment를 받아보세요.

무료 상담 예약

이 블로그 게시물은 이 주제에 대해 자세히 설명하는 것을 목표로 합니다. 소프트웨어 개발자, 프로덕트 매니저 또는 웹 보안의 최신 동향에 관심이 있는 분이라면 패스키 제공자의 역할과 유형을 이해하는 것이 필수적입니다. 이 주제를 명확히 함으로써 사람들이 패스키를 자신 있게 이해할 수 있는 지식을 갖추도록 돕고자 합니다.

패스키 제공자는 사용자의 기기와 신뢰 당사자(온라인 서비스)에 대한 안전하고 원활한 접근을 연결하는 가교 역할을 하며, 패스키 기반 인증 생태계에서 기본적인 역할을 합니다. 그렇다면 패스키 제공자란 정확히 무엇일까요? 특히 공식적인 정의가 없고 온라인에서 다양한 해석을 찾아볼 수 있기 때문에 더욱 궁금할 수 있습니다.

다음 정의는 우리의 이해를 반영한 것이며, 유일하게 정확한 정의라고 주장하지는 않습니다.

패스키 제공자는 본질적으로 패스키의 생성, 관리 및 사용을 가능하게 하는 모든 주체를 의미합니다. 우리는 조사를 통해 패스키 제공자를 분류할 수 있는 두 가지 주요 범주를 파악했습니다. 바로 퍼스트파티 및 써드파티 패스키 제공자와 패스키 인증 제공자입니다.

이 범주에는 클라이언트 측(사용자 기기 내)에서 패스키를 생성할 수 있는 주체가 포함됩니다. 이러한 플랫폼을 통해 패스키가 생성되면, 운영 체제 제조업체의 클라우드(예: iCloud 키체인, Google 비밀번호 관리자) 또는 써드파티 비밀번호 관리자(예: KeePassXC, 1Password, Dashlane - 아래에서 자세히 설명)에 안전하게 관리 및 저장됩니다.

네이티브로 패스키 생성 및 관리를 가능하게 하는 운영 체제는 퍼스트파티 패스키 제공자로 간주됩니다. 반면, API를 통해 플랫폼과 통합되는 써드파티 비밀번호 관리자는 써드파티 패스키 제공자라고 합니다.

하나의 퍼스트파티 또는 써드파티 패스키 제공자는 동일한 AAGUID(Authenticator Attestation Globally Unique Identifiers)를 가지며, 이는 사용자 경험을 개선하는 데 도움이 됩니다(예: 계정 설정에서 패스키를 더 쉽게 구별). 때로는 여러 AAGUID를 가질 수 있으며, 이들은 모두 동일한 퍼스트파티 또는 써드파티 패스키 제공자에 속합니다.

iOS 17.4 기기의 패스키 제공자

Android 14 기기의 패스키 제공자

Android의 Credential Manager API

두 번째 범주는 개발자가 애플리케이션에 통합하여 패스키 관리의 모든 측면을 처리할 수 있는 인증 제공자를 포함합니다. 따라서 이들은 앞서 언급한 클라이언트 측과 달리 서버 측에서 더 많이 작동하는 제공자입니다. 이 정의에는 웹사이트와 앱에 패스키 중심의 인증 솔루션을 제공하는 Corbado와 같은 솔루션도 포함됩니다. 결과적으로, 이러한 패스키 제공자는 앞서 언급한 퍼스트파티 및 써드파티 패스키 제공자와 구별하기 위해 패스키 인증 제공자로 설명하는 것이 더 정확합니다.

이 블로그 게시물의 다음 섹션에서는 앞서 정의한 바에 따라 퍼스트파티 및 써드파티 패스키 제공자를 지칭하기 위해 "패스키 제공자"라는 용어를 사용할 것입니다.

사용자가 다양한 신뢰 당사자(Relying Party)에 대해 패스키를 도입하기 시작하면서, 이를 효과적으로 관리하는 것이 중요한 과제로 떠오르고 있습니다. 단일 계정에 대해 여러 패스키를 사용하는 사용자에게도 마찬가지인데, 신뢰 당사자가 편집이나 삭제를 목적으로 이러한 패스키를 구분하는 것은 복잡할 수 있기 때문입니다. 패스키가 제공하는 편리함과 보안성에도 불구하고, 사용자가 패스키 중 하나를 잃어버리면 잠재적인 문제가 발생할 수 있습니다. 다행히도, 대체 패스키를 사용하여 신뢰 당사자의 계정에 계속 접근할 수 있습니다. 사용자가 특정 패스키를 식별할 수 있도록 돕기 위해, 일부 리소스에서는 계정 설정의 패스키에 생성 및 마지막 사용 날짜와 같은 메타데이터를 추가할 것을 제안합니다. 또한 사용자 에이전트 또는 클라이언트 힌트(client hints)를 활용하여 생성 시 패스키를 자동으로 지정하고 분류하는 것이 권장됩니다. 하지만 네이티브 Android 또는 iOS 앱뿐만 아니라 써드파티 패스키 제공자는 사용자 에이전트를 활용하지 않거나, 해당 패스키가 써드파티 제공자를 통해 생성되었음을 나타내는 정보를 추가하지 않을 수 있습니다. 이러한 한계는 플랫폼이나 제공자에 관계없이 사용자가 패스키를 효율적으로 관리할 수 있도록 돕는 개선된 방법이 필요함을 시사합니다.

W3C의 WebAuthn 사양에서 발췌

이러한 패스키 관리를 용이하게 하기 위해 개발자는 AAGUID(Authenticator Attestation Globally Unique Identifier)를 사용할 수 있습니다. AAGUID는 인증자의 특정 인스턴스가 아닌 인증자 모델에 할당된 고유 식별자입니다. 이는 공개 키 자격 증명의 인증자 데이터에 포함되어 신뢰 당사자가 패스키 제공자를 식별할 수 있는 방법을 제공합니다. 이 기능은 사용자와 신뢰 당사자가 패스키 환경을 탐색하는 데 매우 중요하며, 각 패스키가 생성 출처와 정확하게 연관되도록 보장합니다.

예를 들어, Android 기기에서 Google 비밀번호 관리자를 사용하여 패스키를 생성하면, 신뢰 당사자는 Google 비밀번호 관리자에 고유한 AAGUID를 받을 수 있습니다. 그런 다음 신뢰 당사자는 이 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")를 사용할 수도 있다는 점에 유의해야 합니다.

대부분의 WebAuthn 라이브러리를 사용하면 AAGUID를 검색하는 과정이 간단합니다. 예를 들어, 서버 측에서 SimpleWebAuthn을 사용하는 경우 개발자는 등록 정보에서 AAGUID를 추출하여 알려진 제공자와 일치시킬 수 있으며, 이를 통해 사용자가 패스키를 훨씬 쉽게 관리할 수 있도록 지원합니다(Google의 "AAGUID로 패스키 제공자 결정하기"에서 발췌).

// JSON 파일에서 AAGUID 목록을 가져옵니다.
import aaguids from "./aaguids.json" with { type: "json" };
// ...
// SimpleWebAuthn의 편리한 함수를 사용하여 등록 요청을 확인합니다.
const { verified, registrationInfo } = await verifyRegistrationResponse({
    response: credential,
    expectedChallenge,
    expectedOrigin,
    expectedRPID,
    requireUserVerification: false,
});
// ...
const { aaguid } = registrationInfo;
const provider_name = aaguids[aaguid]?.name || "Unknown";

AAGUID는 패스키 관리를 위한 강력한 도구를 제공하지만 주의해서 사용해야 합니다. AAGUID의 무결성은 패스키 제공자의 진위성을 검증하는 증명(attestation) 과정에 의존합니다. 유효한 증명 서명이 없으면 AAGUID가 조작될 가능성이 있습니다. 2024년 3월 기준, 일부 플랫폼의 패스키는 증명을 지원하지 않으므로 사용 시 신중한 고려가 필요하다는 점에 유의해야 합니다.

다음은 매우 일반적인 패스키 운영 체제 버전 및 브라우저를 사용하는 Android 앱, iOS 앱 및 웹 앱을 위한 퍼스트파티 및 써드파티 패스키 제공자의 일부 목록입니다.

다음은 패스키를 생성/저장할 때 나타나는 써드파티 패스키 제공자 팝업의 일부입니다.

1Password 분석 전문은 여기에서 확인하세요.

Dashlane 분석 전문은 여기에서 확인하세요.

KeePassXC 분석 전문은 여기에서 확인하세요.

패스키 배포 및 관리의 핵심은 패스키 제공자의 역할입니다. 패스키 제공자는 패스키의 생성 및 관리를 용이하게 할 뿐만 아니라 다양한 플랫폼 및 기기 전반에 걸쳐 원활한 통합을 보장하는 주체입니다.

퍼스트파티와 써드파티 제공자의 차이, 그리고 AAGUID(Authenticator Attestation Globally Unique Identifier)의 중요한 역할을 포함하여 패스키 제공자가 무엇인지 이해하는 것이 이 블로그 게시물의 목표였습니다. 논의된 바와 같이 AAGUID를 사용하면 패스키를 더 쉽게 식별하고 관리할 수 있는 유망한 솔루션을 얻을 수 있습니다.

또한 Android, iOS 및 Windows에 현재 존재하는 퍼스트파티 및 써드파티 패스키 제공자가 무엇인지 분석하여, 사용자가 적합한 써드파티 패스키 제공자나 선호하는 기기를 찾는 데 도움을 주고자 했습니다.

개발자와 프로덕트 매니저에게 있어, 패스키 제공자 및 그 관리에 대한 이러한 통찰력은 패스키 인증의 기술적 구현을 안내할 뿐만 아니라, 사용자 경험과 보안을 강화한다는 광범위한 목표와도 일치합니다.

Corbado 소개

Corbado는 대규모로 consumer authentication을 운영하는 CIAM 팀을 위한 Passkey Intelligence Platform입니다. IDP 로그와 일반 analytics 도구가 보여주지 못하는 것을 볼 수 있게 해드립니다: 어떤 디바이스, OS 버전, 브라우저, credential manager가 passkey를 지원하는지, 왜 등록이 로그인으로 이어지지 않는지, WebAuthn 플로우가 어디서 실패하는지, OS나 브라우저 업데이트가 언제 조용히 로그인을 망가뜨리는지 — Okta, Auth0, Ping, Cognito 또는 자체 IDP를 교체하지 않고도 전부 파악할 수 있습니다. 두 가지 제품: Corbado Observe는 passkey 및 다른 모든 로그인 방식에 대한 observability를 더합니다. Corbado Connect는 analytics가 내장된 managed passkey를 제공합니다 (기존 IDP와 함께). VicRoads는 Corbado로 500만+ 사용자에게 passkey를 운영하고 있습니다 (passkey 활성화율 +80%). Passkey 전문가와 상담하기 →