WebAuthn 클라이언트 기능

WebAuthn은 패스키(passkey)를 뒷받침하는 최신 표준입니다. 기존의 비밀번호에 의존하는 대신 공개 키 암호화를 활용하여, 사용자가 생체 인식(지문 또는 얼굴 인식 등)이나 물리적 보안 키를 포함할 수 있는 패스키로 인증할 수 있게 합니다. 이러한 변화는 보안을 강화할 뿐만 아니라 비밀번호 관리의 필요성을 없애 사용자 경험을 개선합니다.

WebAuthn 레벨 3 표준은 개발자와 플랫폼이 패스키를 구현할 때 더 많은 제어권과 유연성을 가질 수 있도록 새로운 클라이언트 기능을 도입했습니다(브라우저 API getClientCapabilities()를 통해 검색 가능). 이러한 업데이트는 여러 기기, 브라우저, 플랫폼에 걸쳐 패스키를 통합하는 과정을 단순화하는 개선 사항을 제공하여 더 원활하고 일관된 사용자 여정을 보장합니다.

이 블로그 게시물에서는 다음 질문에 대해 답해 보겠습니다.

1. WebAuthn 클라이언트 기능이란 무엇인가요?
2. 어떤 WebAuthn 클라이언트 기능이 존재하나요?
3. WebAuthn 클라이언트 기능은 패스키 구현을 어떻게 개선하나요?
4. WebAuthn 클라이언트 기능이 개발자와 제품 관리자 모두에게 왜 중요한가요?

이 글을 다 읽고 나면, 이러한 기능들이 최신 사용자 기대에 부응하는 원활하고 안전한 인증 흐름을 만드는 데 어떻게 도움이 되는지 이해하게 될 것입니다.

WebAuthn 클라이언트 기능은 브라우저와 플랫폼이 어떤 종류의 WebAuthn 기능을 지원하는지 전달할 수 있게 하는 기능 모음입니다. 간단히 말해, 웹사이트에 사용자 기기에서 어떤 인증 방법과 설정을 사용할 수 있는지 알려주는 "기능 체크리스트"처럼 작동합니다. 이를 통해 개발자는 클라이언트의 기능에 따라 인증 흐름을 맞춤화하여 더 원활하고 안전한 사용자 경험을 보장할 수 있습니다.

예를 들어, 브라우저가 생체 인식 인증(Touch ID 등)을 지원한다고 신호를 보내면, 개발자는 사용자가 지문으로 로그인할 수 있는 옵션을 제공하도록 로그인 흐름을 설계할 수 있습니다. 반대로, 브라우저가 특정 기능을 지원하지 않는 경우, 개발자는 비밀번호나 SMS OTP와 같은 대체 옵션을 제공할 수 있습니다.

WebAuthn 레벨 3 표준은 패스키 구현을 더욱 다재다능하고 사용자 친화적으로 만드는 몇 가지 새로운 클라이언트 기능을 도입합니다. getClientCapabilities() API 호출에 대한 첫 지원은 Safari 17.4에서 도입되었습니다.

브라우저에서 지원 여부를 감지하려면 다음 스니펫이 유용할 수 있습니다.

// Check if PublicKeyCredential is supported in the current browser
if (typeof PublicKeyCredential === "undefined") {
    console.log("PublicKeyCredential is not supported in this browser.");
}
 
// Check if getClientCapabilities method exists on PublicKeyCredential
if (typeof PublicKeyCredential.getClientCapabilities === "function") {
    try {
        let capabilities = await PublicKeyCredential.getClientCapabilities();
        console.log(capabilities);
    } catch (error) {
        console.error("Error getting client capabilities:", error);
    }
} else {
    console.log("getClientCapabilities is not supported in this browser");
}

getClientCapabilities()는 웹사이트와 앱이 클라이언트(예: 브라우저 또는 기기)에 어떤 WebAuthn 기능을 지원하는지 질의할 수 있게 합니다. 클라이언트의 기능을 이해함으로써 개발자는 생체 인식 인증과 같은 사용 가능한 기능을 활용하도록 인증 흐름을 최적화하고, 특정 기능이 없는 경우 대체 방법을 제공할 수 있습니다.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

WebAuthn 클라이언트 기능과 이것이 패스키 통합에 미치는 영향에 대해 자세히 살펴보겠습니다.

conditionalCreate는 특정 조건에 따라 패스키 자동 생성을 가능하게 합니다. 애플리케이션은 비밀번호 관리자가 해당 지원을 하는 경우 비밀번호 자동 완성 중에 이 기능을 사용하여 자동으로 패스키를 생성할 수 있습니다. 이 기능은 사용자를 비밀번호에서 패스키로 자동 전환하여 패스키 채택 및 후속 사용을 촉진하는 데 도움이 됩니다.

conditionalCreate와 유사하게, conditionalGet은 패스키 로그인을 자동으로 트리거합니다. 이는 최고의 패스키 UX를 활성화하여 로그인을 비밀번호 없이 할 뿐만 아니라 사용자 이름도 없이(사용자는 모달/드롭다운에서 선택한 패스키를 클릭하기만 하면 인증 가능) 만들어야 하는 시나리오에서 유용합니다. 이 기능을 사용함으로써 개발자는 패스키 인증이 적절할 때만 발생하도록 하여 불필요한 프롬프트를 최소화하고 사용자 경험을 향상시킬 수 있습니다.

hybridTransport는 패스키가 여러 기기에서 사용될 수 있도록 보장하여 원활한 교차 기기 인증(QR 코드 및 블루투스를 통해)을 가능하게 합니다. 예를 들어, 사용자는 스마트폰에 저장된 패스키를 사용하여 데스크톱의 서비스에 로그인할 수 있습니다. 이 기능은 사용자가 각 기기마다 패스키를 수동으로 전송하거나 기존 로그인 방법에 의존할 필요 없이 안전하게 인증할 수 있게 하여 통합된 인증 경험을 조성합니다.

Windows Hello, Face ID 또는 Touch ID와 같은 플랫폼 인증자는 기기에 직접 내장되어 있으며, 사용자가 생체 인식이나 다른 기기 고유의 방법(예: PIN 패턴)으로 인증할 수 있게 하여 더 빠르고, 원활하며, 안전한 패스키 경험을 제공합니다.

Become part of our Passkeys Community for updates & support.

Join

userVerifyingPlatformAuthenticator는 패스키 인증에 활성 지문 스캔이나 얼굴 인식과 같은 사용자 확인이 포함되도록 하여 추가적인 보안 계층을 제공합니다.

relatedOrigins 기능은 동일한 조직이 소유한 다른 도메인(예: amazon.com 및 amazon.de) 간에 원활한 인증을 허용합니다. 예를 들어, 회사가 여러 도메인을 관리하거나 다른 하위 도메인을 가지고 있는 경우, 사용자는 한 번 로그인하면 각 속성에서 다시 인증할 필요 없이 모든 속성에 액세스할 수 있습니다. 이 기능은 사용자 경험을 간소화하고 마찰을 줄이며, 특히 국제 환경이나 다중 서비스 플랫폼을 가진 기업에 유용합니다.

signalAllAcceptedCredentials(options) 메서드는 주어진 사용자에 대한 WebAuthn 자격 증명 ID의 전체 목록을 제공합니다. WebAuthn 신뢰 당사자(Relying Party)는 사용자가 인증되었을 때 개인 정보 유출 위험이 없으므로 signalUnknownCredential() 대신 이 메서드를 사용해야 합니다. 이 메서드는 현재 연결된 인증자에서 업데이트되지 않았을 수 있는 최근 변경 사항을 포함하여 사용자의 공개 키 자격 증명에 대한 포괄적인 개요를 제공합니다.

예를 들어 보겠습니다. 사용자(userId: A)는 Base64URL로 인코딩하면 X와 Y가 되는 자격 증명 ID를 가진 2개의 패스키를 가지고 있습니다. 그런 다음 사용자는 웹 서비스(example.com)의 계정 설정에서 패스키 X를 삭제합니다(따라서 공개 키가 삭제됨). 이제 다음 스니펫을 실행합니다.

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "A", // WebAuthn User Handle, Base64URL.
    allAcceptedCredentialIds: ["Y"],
});

위 코드 실행 시 인증자를 사용할 수 있는 경우, 인증자는 향후 인증 절차에서 패스키 X를 삭제하거나 숨깁니다. 그러나 실행 시점에 인증자가 연결되어 있지 않을 수 있으므로, 신뢰 당사자는 예를 들어 매 로그인 시마다 이 코드를 주기적으로 실행하는 것이 좋습니다.

allAcceptedCredentialIds에 없는 패스키는 제거되거나 숨겨지며, 이는 되돌릴 수 없을 수 있습니다. 따라서 신뢰 당사자는 유효한 WebAuthn 자격 증명 ID가 목록에서 절대 제거되지 않도록 주의를 기울이는 것이 중요합니다. 만약 유효한 자격 증명 ID가 실수로 제거되었다면, 신뢰 당사자는 패스키를 "숨김 해제"하기 위해 가능한 한 빨리 다른 signalAllAcceptedCredentials(options) 호출에 즉시 포함해야 합니다. 만약 패스키가 숨겨진 것이 아니라 제거되었다면, 문제를 해결할 방법은 거의 없습니다.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

signalCurrentUserDetails(options) 메서드는 사용자의 현재 이름과 WebAuthn 표시 이름을 신호로 보냅니다. signalCurrentUserDetails(options)가 호출되면 클라이언트는 이 작업을 실행하기 위해 정의된 일련의 단계를 따릅니다.

예를 들어 보겠습니다. WebAuthn 사용자 ID가 A인 사용자가 웹사이트(example.com)의 계정 설정에서 자신의 이름을 업데이트합니다. 그러면 신뢰 당사자는 다음 코드를 실행할 수 있습니다.

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "A", // user ID, Base64URL.
    name: "New user name",
    displayName: "New display name",
});

그러면 인증자는 로컬에 저장된 패스키의 메타데이터를 업데이트합니다. 가장 큰 이점은 향후 조건부 UI / 패스키 자동 완성 요청 시, 조건부 UI 선택 / 드롭다운 메뉴에 업데이트된 이름과 WebAuthn 표시 이름이 표시된다는 것입니다.

signalUnknownCredential(options) 메서드는 WebAuthn 자격 증명 ID가 WebAuthn 신뢰 당사자에 의해 인식되지 않음을 신호로 보냅니다. 예를 들어 사용자가 패스키를 삭제한 경우입니다. signalAllAcceptedCredentials(options)와 달리, 이 메서드는 허용된 자격 증명 ID의 전체 목록과 WebAuthn 사용자 핸들을 제공할 필요가 없으므로, 인증되지 않은 호출자에게 잠재적인 개인 정보 유출을 방지합니다.

예를 들어 보겠습니다. 사용자가 웹사이트(example.com)의 계정 설정에서 자격 증명 ID가 X인 패스키를 삭제합니다(따라서 공개 키가 삭제됨). 그러나 개인 키는 여전히 사용자 기기에서 사용할 수 있습니다. 이는 향후 조건부 UI / 패스키 자동 완성 로그인 요청(빈 allowCredentials 목록 포함)에서 해당 패스키가 여전히 선택될 수 있음을 의미합니다. 하지만 공개 키가 이미 삭제되었으므로 로그인 시도는 실패할 것이며, 따라서 신뢰 당사자는 다음을 실행해야 합니다.

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "X", // credential ID the user just tried, Base64URL
});

그러면 인증자는 향후 인증 절차에서 자격 증명 ID가 X인 패스키를 삭제하거나 숨깁니다.

WebAuthn 레벨 3 표준이 아직 초안 상태이므로, 이러한 새로운 클라이언트 기능의 채택은 아직 완전히 확산되지 않았습니다. 여러 브라우저가 점진적으로 이러한 기능을 구현하고 있지만 지원 여부는 다양합니다. 아래는 위에서 언급된 주요 브라우저 전반의 사용 가능성에 대한 업데이트된 개요입니다.

레벨 3이 성숙해지고 더 많은 브라우저가 이러한 기능을 탑재함에 따라 채택 속도는 가속화될 것입니다. 지금 당장 얼마나 많은 사용자가 getClientCapabilities()를 활용할 수 있는지 확인하고 싶다면, 무료 Passkeys Analyzer를 사용하여 실제 데이터를 확인할 수 있습니다. 브라우저 릴리스 노트와 관련 문서를 주시하여 호환성이 발전함에 따라 더 넓은 호환성을 계획하세요.

Are your users passkey-ready?

Test Passkey-Readiness

개발자로서, 이러한 새로운 WebAuthn 클라이언트 기능 감지가 자신에게 어떤 의미가 있고 앱에서 어떻게 사용해야 하는지 궁금할 수 있습니다. 다음은 이를 사용하기 위한 권장 사항입니다.

그러나 (2024년 11월 기준) 모든 브라우저가 getClientCapabilities() API 호출을 아직 지원하지는 않는다는 점에 유의하세요. 모든 브라우저가 따라잡을 때까지 사용할 수 있는 폴리필이 여기에 있습니다.

페이지 로드 / 인증 흐름 시작 시 클라이언트가 지원하는 기능을 감지하기 위해 코드 초반에 getClientCapabilities()를 사용하세요. 이를 통해 경험을 동적으로 맞춤화하고, 기기/브라우저에서 작동하는 패스키 기능을 제공할 수 있습니다. 예를 들어, 플랫폼 인증이 지원될 때 이를 유도하거나, 지원되지 않는 경우 대체 방법(예: SMS OTP 또는 하드웨어 보안 키)을 제공할 수 있습니다.

현재 비밀번호를 사용하는 웹사이트/앱에 패스키를 추가하는 경우, conditionalCreate 기능은 패스키 채택률을 높이는 데 큰 도움이 될 수 있습니다. 백그라운드에서, 적합한 자격 증명 관리자(2024년 10월 기준 Apple Passwords만 해당)를 사용한 비밀번호 자동 완성 중에 패스키가 자동으로 생성되며 향후 자동 완성에서 우선적으로 사용됩니다.

높은 패스키 채택률뿐만 아니라 높은 패스키 로그인 사용률을 달성하려면, conditionalGet을 확인하여 기기/브라우저가 조건부 UI / 패스키 자동 완성을 사용할 수 있는지 확인해 보세요. 이렇게 하면 운영 체제/브라우저가 사전에 제안하고 비밀번호 자동 완성보다 훨씬 적은 노력이 필요하므로 사용자가 생성된 패스키를 로그인에 사용하도록 유도할 수 있습니다.

hybridTransport를 활용하여 QR 코드 및 블루투스를 통한 교차 기기 인증을 활성화하여, 사용자가 데스크톱에서 서비스에 액세스하더라도 스마트폰에서 원활하게 로그인할 수 있도록 하세요.

WebAuthn 클라이언트 기능은 현재 존재하는 패스키의 격차를 해소하는 데 있어 중요한 진전을 나타냅니다. 이 블로그 게시물에서는 WebAuthn 클라이언트 기능에 대한 주요 질문을 다루었습니다.

1. WebAuthn 클라이언트 기능이란 무엇인가요? 우리는 이러한 기능이 브라우저와 플랫폼이 특정 기능에 대한 지원을 알릴 수 있게 하여 개발자에게 인증 흐름에 대한 더 많은 제어권을 제공하는 방법을 설명했습니다.
2. 어떤 WebAuthn 클라이언트 기능이 존재하나요? 우리는 getClientCapabilities, conditionalCreate, hybridTransport 등을 포함하여 레벨 3 표준에 도입된 새로운 기능에 대한 개요를 제공했습니다.
3. WebAuthn 클라이언트 기능은 패스키 구현을 어떻게 개선하나요? 우리는 이러한 기능이 통합을 간소화하고, 교차 기기 사용을 향상시키며, 보안을 개선하는 방법에 대해 논의했습니다.
4. WebAuthn 클라이언트 기능이 개발자에게 왜 중요한가요? 이러한 기능은 최신 사용자 기대에 부응하는 원활하고 안전한 인증 경험을 만드는 데 도움이 되어 구현을 더 쉽고 효과적으로 만듭니다.

새로운 WebAuthn 레벨 3 기능을 탐색하고 브라우저 전반의 채택에 대한 최신 정보를 계속 확인하시기를 권장합니다. 패스키를 구현하고 이러한 고급 기능을 활용하고자 한다면, 전문적인 안내와 지원을 위해 저희에게 연락해 주세요.