WebAuthn Conditional UI(패스키 자동 완성) 기술적 설명

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

치트시트 받기

패스키와 그 기반이 되는 WebAuthn 프로토콜의 빠른 도입으로 인증은 많은 사용자에게 더욱 안전하고 사용자 친화적이 되었습니다. 패스키의 눈에 띄는 발전 중 하나는 흔히 "패스키 자동 완성(passkey autofill)" 또는 Conditional Mediation으로 불리는 Conditional UI의 통합입니다 (이 글에서는 Conditional UI라는 용어를 사용하겠습니다).

최근 도입되고 브라우저에 지속적으로 적용되고 있음에도 불구하고, Conditional UI에 대한 기술 문서 및 구현 조언에는 눈에 띄는 공백이 있습니다. 이 글은 Conditional UI가 무엇인지, 어떻게 작동하는지, 그리고 구현 중에 발생하는 일반적인 문제를 해결하는 방법을 설명함으로써 그 간극을 메우고자 합니다.

Conditional UI는 패스키 / WebAuthn 로그인 프로세스의 새로운 모드를 나타냅니다. 사용자가 기기(예: 노트북, 스마트폰)의 인증기에 저장된 신뢰 당사자(relying party, 온라인 서비스)에 등록된 발견 가능한 자격 증명(상주 키)을 가지고 있는 경우에만 선택적으로 패스키를 UI에 표시합니다. 패스키는 자동 완성된 비밀번호와 혼합된 선택 드롭다운에 표시되어 사용자가 동일한 컨텍스트에서 둘 다 볼 수 있으므로 전통적인 비밀번호 시스템과 고급 패스키 인증 간의 원활한 전환을 제공합니다. 이 지능적인 접근 방식은 사용자가 불필요한 옵션에 압도되지 않고 로그인 프로세스를 더 원활하게 탐색할 수 있도록 보장합니다.

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

Conditional UI의 기반은 세 가지 주요 기둥으로 구축됩니다.

1. 사용자 개인정보 보호 존중: 사용 가능한 자격 증명의 공개 또는 이러한 자격 증명을 공개하기 위한 사용자 동의 부족을 방지하여 사용자 개인정보를 보호합니다.
2. 패스키가 없어도 훌륭한 사용자 경험: 신뢰 당사자가 WebAuthn을 상황에 맞게 구현할 수 있도록 지원하여 패스키를 사용할 수 없는 경우에도 사용자 경험이 좋게 유지되도록 합니다.
3. 비밀번호에서 패스키로의 원활한 전환: 사용자의 친숙한 UX 패러다임을 활용하여 비밀번호 없는 인증 방법으로의 전환을 원활하게 하기 위해 패스키를 비밀번호 기반 인증과 결합합니다.

• 간소화된 인증: 프로세스가 더 간소화되고 효율적이 되어 여러 인증 방법과 관련된 복잡성을 제거합니다.
• 사용자 오류 감소: 관련 옵션만 제시함으로써 사용자가 인증 과정에서 실수할 가능성을 줄입니다.
• 사용자 만족도 향상: 불필요한 단계를 제거하면 사용자가 더 빠르고 쉽게 로그인할 수 있어 사용자 만족도가 향상됩니다.
• 간단한 프런트엔드 통합: Conditional UI의 돋보이는 기능 중 하나는 통합의 용이성입니다. 개발자는 몇 줄의 코드로 프런트엔드에 원활하게 통합할 수 있습니다(아래 참조).
• 비밀번호 없는 로그인과 사용자 이름 없는 로그인: Conditional UI의 큰 이점 중 하나는 비밀번호 없는 인증뿐만 아니라 사용자 이름이 없거나 계정이 없는 경험을 촉진한다는 것입니다. 사용자는 가입할 때 사용한 특정 이메일 주소나 사용자 핸들을 기억해야 하는 정신적 부담을 덜게 됩니다. 대신, 브라우저의 제안에 의존할 수 있으며, 이 제안에는 자동 완성 메뉴에 적절한 패스키와 짝을 이룬 이메일 주소/사용자 핸들이 포함됩니다.
• 부트스트래핑 딜레마 해결: 전통적인 사용자 이름-비밀번호 시스템에서 패스키로의 전환은 벅찰 수 있습니다. Conditional UI는 이러한 전환 문제를 해결합니다. 웹사이트는 기기에 필요한 자격 증명이 없을 경우 발생할 수 있는 잠재적인 모달 대화 상자 오류에 대해 걱정하지 않고 일반적인 비밀번호 프롬프트와 함께 패스키 / WebAuthn 호출을 시작할 수 있습니다.

최신 뉴스를 위해 Passkeys Substack을 구독하세요.

구독하기

• 개발자를 위한 학습 곡선: Conditional UI는 새로운 패러다임을 도입하므로 복잡성에 익숙하지 않은 개발자에게는 학습 곡선이 수반됩니다.
• 기기 / 브라우저 종속성: Conditional UI의 성공은 사용자의 기기 또는 브라우저 호환성에 달려 있습니다. 현재 모든 브라우저나 기기가 지원하는 것은 아니기 때문에 적용이 제한될 수 있습니다.
• 비밀번호 관리자의 자동 완성 비활성화: 일부 최신 비밀번호 관리자 및 해당 브라우저 확장 프로그램은 웹사이트의 DOM을 수정하고 자체 자동 완성 기능을 위해 입력 필드의 autocomplete 태그를 비활성화하거나 덮어씁니다. 이로 인해 일관성 없고 불만족스러운 사용자 경험이 발생할 수 있습니다. Conditional UI의 표준이 비교적 새롭기 때문에 두 개의 자동 완성 메뉴가 겹치거나 원하는 메뉴가 전혀 표시되지 않는 등의 상황이 개선되기를 바랍니다.

다음에서는 전체 Conditional UI 흐름의 각 단계를 단계별로 분석해 보겠습니다.

일반적으로 Conditional UI 프로세스 흐름은 두 단계로 나눌 수 있습니다. 페이지 로드 단계에서는 Conditional UI 로직이 백그라운드에서 발생하며, 사용자 조작 단계에서는 사용자가 적극적으로 무언가를 수행해야 합니다.

1. Conditional UI 가용성 확인: 클라이언트(브라우저)는 isConditionalMediationAvailable() 함수를 호출하여 현재 브라우저 / 기기 조합이 Conditional UI를 지원하는지 감지합니다. 응답이 true인 경우에만 프로세스가 계속되고, 그렇지 않으면 Conditional UI 프로세스가 중단됩니다.
2. Conditional UI 엔드포인트 호출: 다음으로 클라이언트는 PublicKeyCredentialRequestOptions를 검색하기 위해 서버의 Conditional UI 엔드포인트를 호출합니다.
3. PublicKeyCredentialRequestOptions 수신: 서버는 과제(challenge) 및 더 많은 WebAuthn 서버 옵션(예: allowCredentials, extensions, userVerification)을 포함하는 PublicKeyCredentialRequestOptions를 반환합니다.
4. 로컬 인증 시작: 수신된 PublicKeyCredentialRequestOptions와 mediation 속성이 conditional로 설정된 상태에서 credentials.get()을 호출하면 기기에서 로컬 인증 프로세스가 시작됩니다.
5. 자동 완성 선택 표시: 패스키에 대한 자동 완성 메뉴가 나타납니다. 특정 스타일링은 브라우저와 기기에 따라 다릅니다(예: 일부는 사용자가 커서를 입력 필드에 두어야 하고, 일부는 페이지 로드 시 메뉴를 자동으로 표시합니다. 아래 참조).
6. 로컬 사용자 인증: 사용자는 자동 완성 메뉴에서 사용하려는 패스키를 선택하고 기기의 인증 대화 상자(예: Face ID, Touch ID, Windows Hello)를 통해 인증합니다.
7. 서버로 인증기 응답 전송: 로컬 사용자 인증에 성공하면 인증기 응답이 서버로 다시 전송됩니다.
8. 사용자 로그인 및 리디렉션: 서버가 인증기 응답을 받으면 데이터베이스에 있는 해당 사용자 계정의 공개 키에 대해 서명을 유효성 검사합니다. 검증이 성공하면 사용자에게 액세스 권한이 부여되고, 로그인되며, 로그인된 페이지로 리디렉션됩니다.

이 프로세스 흐름을 따르면 Conditional UI는 원활하고 사용자 친화적인 인증 경험을 제공합니다.

Conditional UI를 작동시키려면 몇 가지 일반적인 측면을 고려해야 합니다.

• 자격 증명 사양: Conditional UI는 상주 키 / 발견 가능한 자격 증명과만 작동하도록 특별히 설계되었습니다. 그 이유는 인증기가 비상주 키 / 발견할 수 없는 자격 증명에 대해 사용자 특정 데이터(예: 이름, 표시 이름)를 저장하지 않기 때문입니다. 결과적으로 후자를 패스키 자동 완성에 사용하는 것은 불가능합니다.
• 자격 증명 필터링: allowCredentials 기능은 계속 지원되어 사용자의 ID를 이미 알고 있는 웹사이트(예: 사용자 핸들이 브라우저의 LocalStorage에 저장되어 있을 수 있으므로 초기 mediation 호출에서 전송된 경우)가 자동 완성 중에 사용자에게 표시되는 자격 증명 목록을 정제할 수 있도록 용이하게 합니다.

업데이트와 지원을 위해 Passkeys Community에 참여하세요.

참여하기

클라이언트 측에서 Conditional UI를 작동시키려면 다음 요구 사항을 충족해야 합니다.

• 호환되는 브라우저: 사용자가 Conditional UI를 지원하는 최신 브라우저를 사용하는지 확인하십시오 (최신 브라우저 범위는 여기 참조).
• JavaScript 활성화: Conditional UI 작업을 원활하게 하려면 JavaScript를 활성화해야 합니다.
• Conditional UI 가용성 테스트: 신뢰 당사자(서버 측)는 WebAuthn mediation 호출을 받을 때 클라이언트 측에서 Conditional UI를 사용할 수 있다는 확신을 가져야 하며 Conditional UI가 지원되지 않는 시나리오에서 사용자에게 표시되는 오류를 유발하지 않아야 합니다. 이 문제를 해결하려면 isConditionalMediationAvailable() 메서드를 사용하여 Conditional UI의 기술적 가용성을 확인하는 것이 좋습니다 (자세한 내용은 아래 참조).
• HTML 입력 필드 필수: Conditional UI가 작동하려면 웹 페이지에 HTML 입력 필드가 있어야 합니다. 없는 경우 버튼 클릭과 같은 사용자 상호 작용으로 트리거되는 일반적인 패스키 / WebAuthn 로그인 프로세스에 대한 지원을 제공해야 합니다.
• 시간 초과 프로토콜 제거: 시간 초과 매개변수(예: 사용자가 자동 완성 메뉴에서 패스키를 결정하는 데 시간이 너무 오래 걸림)는 이 설정에서 무시되어야 합니다.

Conditional UI를 작동시키려면 서버 측의 몇 가지 요구 사항도 충족해야 합니다.

• 실행 중인 WebAuthn 서버: 패스키 / WebAuthn 컨텍스트에 계속 있기 때문에 인증 절차를 관리하는 실행 중인 WebAuthn 서버가 필요합니다.
• Mediation 시작 엔드포인트 제공: 일반 WebAuthn 로그인 엔드포인트와 비교하여 유사한 기능이 있지만 선택적인 사용자 핸들(예: 이메일 주소, 전화번호, 사용자 이름)을 처리할 수 있는 다른 엔드포인트를 제공하는 것이 유용합니다.

2022년 말 Conditional UI의 공식 출시 및 초기 베타 버전 이후, 당사는 이에 대해 광범위하게 테스트하고 작업해 왔습니다. 다음에서는 Conditional UI 구현 중에 도움이 되었던 실용적인 팁을 공유하고자 합니다.

Passkeys Debugger에서 passkey 흐름을 실험하세요.

무료로 체험하기

Conditional UI 메서드의 전체, 최소주의적 코드 예제는 다음과 같습니다.

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Conditional UI</title>
    </head>
    <body>
        <input type="text" id="username" autocomplete="username webauthn" />
 
        <script>
            async function passkeyLogin() {
                try {
                    // retrieve the request options (incl. the challenge) from the WebAuthn server
                    let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
                    const credential = await navigator.credentials.get({
                        publicKey: options.publicKeyCredentialRequestOptions,
                        mediation: "conditional",
                    });
 
                    const userData = await WebAuthnClient.sendSignedChallenge(credential);
                    window.location.href = "/logged-in";
                } catch (error) {
                    console.log(error);
                }
            }
 
            passkeyLogin();
        </script>
    </body>
</html>

현재 기기 / 브라우저 조합이 지원할 때만 Conditional UI가 사용되도록 하는 Conditional UI 감지를 구현합니다. 이것은 Conditional UI 지원이 없을 때 사용자에게 표시되는 오류 없이 작동해야 합니다. 사용자 인터페이스 내에 isConditionalMediationAvailable() 메서드를 통합하면 이 문제를 해결할 수 있습니다. Conditional UI 지원이 제공되면 Conditional UI 로그인 프로세스를 시작할 수 있습니다.

// source: https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/isConditionalMediationAvailable#examples
 
// Availability of `window.PublicKeyCredential` means WebAuthn is usable.
if (window.PublicKeyCredential && PublicKeyCredential.isConditionalMediationAvailable) {
    // Check if conditional mediation is available.
    const isCMA = await PublicKeyCredential.isConditionalMediationAvailable();
    if (isCMA) {
        // Call WebAuthn authentication start endpoint
 
        let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
        const credential = await navigator.credentials.get({
            publicKey: options.publicKeyCredentialRequestOptions,
            mediation: "conditional",
        });
        /*
        ...
        */
    }
}

입력 필드는 webauthn HTML 자동 완성 토큰을 받아야 합니다. 이것은 진행 중인 요청에 패스키를 채우도록 클라이언트에 신호를 보냅니다. 패스키 외에도 다른 자동 완성 값이 표시될 수도 있습니다. 이러한 자동 완성 토큰은 다른 기존 토큰과 쌍을 이룰 수 있습니다. 예:

• autocomplete="username webauthn": 패스키를 표시하는 것 외에도 사용자 이름 자동 완성을 제안합니다.
• autocomplete="current-password webauthn": 패스키를 표시하는 것 외에도 비밀번호 자동 완성을 추가로 프롬프트합니다.

<label for="name">Username:</label>
<input type="text" name="name" autocomplete="username webauthn" />
<label for="password">Password:</label>
<input type="password" name="password" autocomplete="current-password webauthn" />

자세한 내용은 패스키 및 비밀번호에 대한 자동 완성 / autocomplete 토큰에 대한 자세한 내용을 제공하는 이 블로그 게시물을 읽어 보시기 바랍니다.

PublicKeyCredentialRequestOptions 객체를 받은 후 사용 가능한 패스키를 검색하려면 navigator.credentials.get() 함수를 호출해야 합니다(이 함수는 패스키와 비밀번호 모두를 제공함). 클라이언트에서 Conditional UI를 활성화하려면 PublicKeyCredentialRequestOptions 객체의 mediation 매개변수가 conditional로 설정되어야 합니다. 모달 패스키 프롬프트를 원하는 경우에는 즉각적인 mediation(immediate mediation)을 참조하십시오.

const credential = await navigator.credentials.get({
    publicKey: options.publicKeyCredentialRequestOptions,
    mediation: "conditional",
});

사용 가능한 패스키가 없거나 사용자가 제안된 패스키를 무시하고 이메일을 입력하면 Conditional UI 흐름이 중지됩니다. 이는 모달을 통한 표준 패스키 / WebAuthn 로그인을 항상 지원하는 것의 중요성을 강조합니다.

여기서 강조해야 할 중요한 점은 진행 중인 Conditional UI 요청을 중단해야 할 잠재적 필요성입니다. 모달 환경과 달리 자동 완성 드롭다운에는 취소 버튼이 없습니다. WebAuthn의 설계에 따라 한 번에 단일 활성 자격 증명 요청만 진행 중이어야 합니다. WebAuthn 표준은 일반 로그인 프로세스와 Conditional UI 로그인 프로세스 모두에 적용할 수 있는 WebAuthn 프로세스를 취소하기 위해 AbortController를 활용할 것을 제안합니다(자세한 내용은 여기 참조).

프로덕션 원격 분석(telemetry)에서 이러한 취소 경로는 종종 예상되는 제어 흐름의 결과이며 시스템 장애가 아닙니다. 많은 양의 오류가 발생하는 경우 이를 회귀(regressions)로 취급하기 전에 작업 유형 및 타이밍별로 예상되는 경우와 예상치 못한 경우를 분류해야 합니다(WebAuthn 오류 참조).

Conditional UI 로그인 프로세스는 사용자가 페이지에 방문하는 즉시 활성화됩니다. 첫 번째 작업은 전역 범위의 AbortController 객체를 생성하는 것이어야 합니다. 이것은 특히 사용자가 일반 패스키 로그인 프로세스를 수행하기로 결정한 경우 클라이언트가 자동 완성 요청을 종료하라는 신호로 작용합니다. AbortController가 다른 함수에 의해 호출될 수 있고 Conditional UI 프로세스를 다시 시작해야 하는 경우 재설정되는지 안심시키십시오. navigator.credentials.get() 호출 내에서 signal 속성을 활용하고 AbortController 신호를 해당 값으로 통합합니다. 이것은 신호가 중단되면 요청을 중지해야 함을 패스키 / WebAuthn 함수에 알립니다. Conditional UI를 트리거할 때마다 매번 새로운 AbortController를 설정하는 것을 잊지 마십시오. 이미 중단된 AbortController를 사용하면 패스키 / WebAuthn 함수가 즉시 취소됩니다. 나머지 단계는 일반적인 패스키 로그인 프로세스와 일치합니다. 다음에서 언급된 단계의 코드 예제를 볼 수 있습니다.

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Conditional UI</title>
    </head>
    <body>
        <input type="text" id="username" autocomplete="username webauthn" />
 
        <script>
            async function passkeyLogin() {
                try {
                    // retrieve the request options (incl. the challenge) from the WebAuthn server
                    let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
                    const credential = await navigator.credentials.get({
                        publicKey: options.publicKeyCredentialRequestOptions,
                        mediation: "conditional",
                    });
 
                    const userData = await WebAuthnClient.sendSignedChallenge(credential);
                    window.location.href = "/logged-in";
                } catch (error) {
                    console.log(error);
                }
            }
 
            passkeyLogin();
        </script>
    </body>
</html>

Conditional UI 지원이 없는 경우 사용자를 일반 패스키 로그인 프로세스로 안내합니다. 이 경로를 제공하는 것은 하드웨어 보안 키(예: YubiKeys)를 사용하는 사용자나 인증기 제약으로 인해 비상주 키 / 발견할 수 없는 자격 증명을 사용해야 하는 사용자에게 중요합니다.

실제로 얼마나 많은 사람이 passkeys를 쓰는지 확인하세요.

도입 데이터 보기

iOS 또는 Android 용 네이티브 앱을 개발할 때 Conditional UI도 작동합니다. Flutter, Kotlin 또는 Swift로 네이티브로 구현하든, 아니면 Chrome Custom Tabs CCT나 SFSafariViewController 또는 SFAuthenticationSession / ASWebAuthenticationSession을 사용하기로 결정하든 상관없습니다. 두 접근 방식 모두 Conditional UI를 지원합니다.

일반적으로 iOS 앱에 대한 Conditional UI 지원을 구현하는 방법에 대한 문서를 거의 찾지 못했습니다. 그러나 연구 과정에서 iOS 앱에 Conditional UI 지원을 추가하는 두 가지 방법을 발견했으며, 사용자 경험 또한 다릅니다.

타입 A: 거의 전체 화면에 대한 오버레이 / 팝업

첫 번째 타입 A는 거의 전체 화면에 걸친 오버레이 / 팝업을 보여줍니다. 여기에서 해당 신뢰 당사자에 대해 사용 가능한 모든 패스키를 볼 수 있습니다. 이러한 방식으로 Conditional UI를 구현하는 눈에 띄는 예는 KAYAK입니다. 사용자가 올바른 화면을 열면 오버레이 / 팝업이 자동으로 나타납니다.

타입 B: 키보드 자동 완성

두 번째 타입 B는 키보드의 자동 완성 섹션(비밀번호 자동 완성이 제안되는 곳이기도 함)에 적합한 패스키를 표시합니다. 제안된 값을 클릭하면 Face ID 인증이 수행되고 로그인할 수 있습니다. Corbado 개발자 패널의 현재 iOS 앱 버전에서는 이와 같이 구현했습니다(WebAuthn 사용자 이름과 함께 <신뢰 당사자 ID> 메시지에 패스키로 로그인을 확인하세요). 표시하려면 사용자가 입력 필드를 탭해야 합니다.

이 신뢰 당사자에 대해 사용 가능한 모든 패스키를 조회하는 캐싱이 백그라운드에서 발생하기 때문에 이 키보드 섹션의 패스키 자동 완성 기능은 iOS가 새로 설치되었을 때 문제가 있을 수 있습니다.

제안된 패스키 오른쪽에 있는 키 아이콘을 클릭하면 iOS에서 비밀번호 / 패스키를 선택하는 것으로 알려진 사이트로 연결됩니다.

공식 문서를 찾지 못했으며 당사의 통찰력은 적절한 구현에 대한 구체적인 증거보다는 당사의 경험과 가설에 기반한다는 점을 참고하십시오.

Android의 경우, Android Credential Manager API를 활용하는 Conditional UI / 패스키 자동 완성을 위한 한 가지 타입만 있기 때문에 Conditional에 대한 이야기가 조금 더 명확합니다(문서는 여기 참조). Android 제공업체는 다를 수 있으므로 브라우저 전용 WebAuthn 실패 패턴과 별도로 Credential Manager 패스키 오류를 모니터링하십시오.

Conditional UI가 구현된 페이지를 열면 다음 화면이 표시되며, 여기서 다양한 로그인 방법을 찾을 수 있습니다.

**저장된 더 많은 로그인(More saved sign-ins)**을 클릭하면 로그인을 위해 선택할 수 있는 더 많은 옵션이 제공됩니다(기기 간 인증 및 Samsung Pass 또는 1Password와 같은 다른 패스키 동기화 플랫폼의 선택 포함).

최종 사용자에게 Conditional UI가 어떻게 보이는지 설명하기 위해 https://passkeys.eu를 사용하는 Conditional UI 자동 완성 메뉴의 여러 스크린샷을 추가했습니다.

라이브 데모에서 passkeys를 체험하세요.

Passkeys 체험하기

실제 애플리케이션의 몇 가지 일반적인 시나리오를 살펴보겠습니다.

사이트에 저장된 패스키가 없는 경우 브라우저와 OS에 따라 Conditional UI가 다르게 작동합니다.

macOS의 Chrome에서는 입력 필드를 클릭하면 빈 자동 완성 드롭다운이 표시됩니다.

macOS의 Safari에서는 드롭다운이 표시되지 않고 입력 필드에 미묘한 아이콘만 나타납니다.

Android 또는 iOS에서는 사용자가 필드를 탭하고 OS가 일치하는 자격 증명을 찾는 경우에만 자동 완성 인터페이스가 나타납니다.

이러한 다양성은 의도된 것이며 WebAuthn의 개인정보 보호 모델의 일부입니다. 사용자가 패스키를 적극적으로 선택하지 않는 한 웹사이트는 패스키 존재 여부를 감지할 수 없습니다.

사용자가 여러 패스키 제공자(예: iCloud Keychain, Google Password Manager, 1Password)를 설치한 경우, 브라우저나 OS는 일반적으로 사용자의 기본 자격 증명 관리자를 기본값으로 설정합니다.

패스키를 지원하는 다양한 패스키 제공자 / 자격 증명 관리자 목록을 보려면 다음 GitHub 링크를 살펴보는 것이 좋습니다.

Android에서 Credential Manager는 Samsung Pass 또는 1Password와 같은 다양한 공급업체를 노출합니다.

1. 사용자 식별자 입력 필드를 클릭하면 사용자가 패스키를 선택할 수 있는 이 메뉴가 나타납니다.

2. 이전 화면에서 사용자가 "더 많은 패스키(More passkeys)"를 클릭하면 다른 패스키 제공자 / 자격 증명 관리자 및 패스키의 사전 선택이 표시됩니다.

3. 이전 화면에서 사용자가 "저장된 더 많은 로그인(More saved sign-ins)"을 클릭하면 사용자가 패스키를 선택할 수 있는 전체 사용 가능 목록이 나타납니다.

iOS에서는 키 아이콘을 통해 다양한 출처의 패스키 전체 목록이 열립니다.

1. 먼저 iOS 18+에서는 기본 패스키 제공자가 포함된 일반 Conditional UI가 나옵니다.

2. 키보드 아이콘을 클릭하면 다음 선택 메뉴가 나타납니다.

3. 자격 증명 관리자 / 패스키 제공자를 선택한 후 사용자는 사용할 패스키를 선택할 수 있습니다.

Conditional UI / 패스키 자동 완성 기능을 갖춘 패스키는 온라인에서 인증하는 새로운 방법입니다. 비밀번호가 패스키로 점점 더 많이 대체되는 시대로 전환함에 따라 강력하고 사용자 친화적인 전환 메커니즘에 대한 필요성은 의심할 여지가 없습니다. 이 글은 전환 과정에 큰 도움이 되는 Conditional UI를 올바르게 구현하는 방법과 특히 주의해야 할 측면을 이해하는 데 도움이 되었기를 바랍니다.

Corbado 소개

Corbado는 대규모로 consumer authentication을 운영하는 CIAM 팀을 위한 Authentication 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 전문가와 상담하기 →

PublicKeyCredential.isConditionalMediationAvailable()을 호출하고 true를 반환하는 경우에만 진행하세요. 이 검사는 지원되지 않는 브라우저 및 기기 조합에서 사용자에게 표시되는 오류를 방지합니다. 이 메서드는 navigator.credentials.get()에 mediation: "conditional"을 사용하여 호출하기 전, 모든 페이지 로드 시 평가되어야 합니다.

인증기는 상주 키(발견 가능한 자격 증명)에 대해서만 이름 및 표시 이름과 같은 사용자 특정 데이터를 저장합니다. 비상주 키는 이 정보를 유지하지 않으므로 자동 완성 메뉴에 사용자가 선택할 계정 세부 정보를 채울 수 없습니다.

동작은 플랫폼마다 다릅니다. macOS의 Chrome은 빈 자동 완성 드롭다운을 표시하고, macOS의 Safari는 입력 필드에 미세한 아이콘만 표시하며, Android 또는 iOS에서는 사용자가 필드를 탭한 후 OS가 일치하는 자격 증명을 찾는 경우에만 자동 완성 인터페이스가 나타납니다. 이러한 차이는 의도된 것으로 WebAuthn의 개인 정보 보호 모델의 일부입니다. 사용자가 능동적으로 선택하지 않는 한 웹사이트는 패스키가 존재하는지 여부를 알 수 없습니다.

전역 스코프의 AbortController를 생성하고 해당 신호를 navigator.credentials.get()에 전달하세요. 사용자가 모달 로그인 흐름을 시작하면 컨트롤러에서 .abort()를 호출합니다. 이미 중단된 컨트롤러를 재사용하면 WebAuthn 요청이 즉시 취소되므로 Conditional UI가 다시 시작될 때마다 항상 새로운 AbortController를 인스턴스화하세요.

Conditional UI는 네이티브 iOS 및 Android 앱 모두에서 작동합니다. iOS는 전체 화면 오버레이 팝업과 키보드 자동 완성 제안의 두 가지 변형을 지원합니다. Android는 Credential Manager API를 사용하며, 이를 통해 Samsung Pass 또는 1Password와 같은 여러 제공업체의 패스키를 표시할 수 있습니다.