WebAuthn 전송: 내부 및 하이브리드 전송

엔터프라이즈 Passkey 백서. passkey 프로그램을 위한 실무 가이드, 도입 패턴, KPI.

백서 받기

참고: WebAuthn 사양에 따라, 비어 있는 전송 시퀀스는 전송 정보를 사용할 수 없거나 개인정보 보호를 위해 보류되었음을 의미합니다. 종종 브라우저에서는 모든 전송이 가능할 수 있는 것으로 간주합니다.

다양한 플랫폼에서 패스키를 구현할 때 개발자는 중요한 결정에 직면하게 됩니다.

• 최적의 교차 기기 인증 경험을 보장하기 위해 WebAuthn 전송, 특히 내부 및 하이브리드 전송을 어떻게 처리해야 할까요?

해답은 인증기가 신뢰 당사자와 통신하는 방법을 결정하는 기술적 세부 사항인 WebAuthn 전송을 이해하는 데 있습니다. 이론상 전송은 간단해 보이지만, 웹 브라우저, 네이티브 iOS 및 네이티브 Android 애플리케이션 전반에 걸쳐 구현 방식, 특히 내부 및 하이브리드 전송 처리가 크게 다릅니다.

이 문서에서는 다양한 플랫폼에서 WebAuthn 전송이 어떻게 작동하는지 검토하고, 내부 및 하이브리드 전송을 처리하는 두 가지 다른 접근 방식과 각각의 장단점을 제시합니다.

이 문서에서 다루는 내용:

1. WebAuthn 전송: 웹, iOS 및 Android 전반의 내부, 하이브리드 및 플랫폼 인증기
2. 두 가지 접근 방식: 사양 준수 대 최적화된 내부 및 하이브리드 전송 처리
3. 교차 기기 인증 구현 모범 사례 및 권장 사항

WebAuthn 전송은 인증기와 클라이언트 기기 간의 통신 방법을 정의합니다. WebAuthn 레벨 3 사양은 6가지 전송 유형을 정의합니다.

usb: YubiKey 또는 기타 FIDO2 보안 토큰과 같이 USB 포트를 통해 연결되는 하드웨어 보안 키에서 사용됩니다.

nfc: 근거리 무선 통신(NFC)을 통해 인증기와의 통신을 활성화하여 사용자가 보안 키 또는 NFC 지원 기기를 탭할 수 있도록 합니다.

ble: Bluetooth Low Energy를 통한 인증을 용이하게 하여 외부 인증기와의 무선 통신을 가능하게 합니다.

smart-card: 스마트 카드 리더기에서 사용되며 스마트 카드를 통한 인증을 허용합니다.

hybrid: 주로 사용자가 QR 코드를 스캔하여 기기 간 인증(예: 휴대폰을 사용하여 데스크톱 브라우저에서 인증하거나 그 반대)을 수행하는 교차 기기 인증을 활성화합니다. 이 전송은 데스크톱 및 모바일 기기 모두에서 QR 코드 프롬프트를 트리거할 수 있으며, 컨텍스트에 따라 항상 바람직한 것은 아닐 수 있습니다. 참고: hybrid는 WebAuthn 레벨 3에서 추가되었습니다.

internal: iPhone의 iCloud Keychain(Face ID 또는 Touch ID를 통해 확인됨), PC의 Windows Hello 또는 Android 기기의 Google Password Manager처럼 인증기가 기기 자체에 내장되어 있습니다. 이들은 플랫폼 인증기입니다.

패스키가 생성될 때 인증기는 지원하는 전송을 신호로 보냅니다. 이 정보는 신뢰 당사자(백엔드)로 전송되며, 크리덴셜과 함께 유지되어야 합니다. 인증하는 동안 신뢰 당사자는 이 전송들을 allowCredentials 목록에 넣어 클라이언트로 다시 보내어, 브라우저나 플랫폼이 사용자에게 제공할 인증 방법을 결정하도록 돕습니다.

전송 처리는 플랫폼에 따라 크게 다르기 때문에 개발자가 직면하는 호환성 문제가 발생합니다.

브라우저는 인증기로부터 전송 정보를 수신하고 인증 흐름 중에 이를 존중합니다. Chrome, Safari 또는 Edge에서 패스키를 생성할 때, 브라우저의 크리덴셜 관리자는 기본 인증기에 따라 달라지는 전송 데이터를 제공합니다.

플랫폼 인증기: Windows Hello는 기기 종속적 특성을 반영하여 ["internal"]만 제공합니다. 그러나 Chrome이 Google Password Manager를 인증기로 사용하는 경우 Google Password Manager가 Android 휴대폰을 통한 교차 기기 인증을 지원하기 때문에 ["internal", "hybrid"]를 제공합니다.

하드웨어 보안 키: 실제 기능에 따라 ["usb", "nfc"]와 같은 특정 전송을 제공합니다.

클라우드 동기화 크리덴셜 관리자: Safari의 iCloud Keychain 및 Chrome의 Google Password Manager는 로컬 및 교차 기기 인증 흐름을 모두 지원하기 위해 일반적으로 ["internal", "hybrid"]를 제공합니다.

이 정보는 웹 컨텍스트에서 안정적으로 흐르지만, 구체적인 전송은 크리덴셜 저장을 위해 브라우저가 어떤 인증기를 선택하느냐에 따라 다릅니다.

문서: W3C WebAuthn 사양

Android의 Credential Manager API는 웹 브라우저와 유사하게 동작합니다. 네이티브 Android 앱에서 패스키를 생성할 때, Credential Manager는 웹 동작을 반영하는 전송 정보를 제공합니다. 플랫폼 인증기는 그 기능을 정확하게 보고하고 시스템은 전송 데이터를 일관되게 처리합니다. Android 개발자는 특별한 처리 없이 이 정보를 신뢰할 수 있습니다.

문서: Android Credential Manager

iOS는 더 복잡한 상황을 제시합니다. Apple의 AuthenticationServices 프레임워크는 인증기 유형에 따라 전송을 다르게 처리합니다.

플랫폼 인증기 (iCloud Keychain, Face ID 또는 Touch ID를 통해 확인됨): 패스키 생성 중에 종종 빈 전송 배열을 반환합니다. 이는 전송 정보를 사용할 수 없거나 개인정보 보호를 위해 보류되었음을 나타냅니다. WebAuthn 사양에 따라 전송 정보를 알 수 없거나 개인정보를 보호하기 위해 사용자 에이전트는 빈 시퀀스를 반환할 수 있습니다. 신뢰 당사자는 전송을 보장된 기능이 아닌 힌트로 취급해야 합니다.

보안 키: iOS 기기와 함께 사용될 때 예상되는 패턴에 따라 전송 정보(예: ["usb"], ["nfc"])를 제공합니다.

문서: Apple AuthenticationServices

웹 및 네이티브 애플리케이션의 실제 프로덕션 데이터를 분석하면 빈도순으로 정렬된 다음 전송 패턴을 확인할 수 있습니다. 이 분포는 구현 세부 사항과 클라이언트 인구 통계(모바일 대 데스크톱 사용, 네이티브 앱의 가용성)에 영향을 받지만, 일반적인 전송 사용에 대한 귀중한 통찰력을 제공합니다.

주요 통찰력:

플랫폼 인증기의 지배: 패스키의 대다수는 internal 전송을 사용하며, 교차 기기 인증 지원을 위해 hybrid와 결합되는 경우가 많습니다. 이는 플랫폼 인증기(iCloud Keychain, Google Password Manager)에 대한 소비자 중심의 초점을 반영합니다.

빈 배열의 보편성: iOS 네이티브 애플리케이션은 종종 플랫폼 인증기에 대해 빈 전송 배열을 반환하며, 이는 실제 프로덕션 크리덴셜의 상당 부분을 차지합니다. 2.2.3 섹션에서 논의한 바와 같이, 이는 포괄적인 전송 지원이라기보다 전송 정보를 사용할 수 없음을 나타냅니다.

보안 키의 희소성: 하드웨어 보안 키(usb, nfc)는 프로덕션 패스키의 아주 작은 부분을 차지하며, 소비자 애플리케이션보다는 주로 엔터프라이즈 또는 고보안 시나리오에서 사용됨을 나타냅니다.

순서의 차이: 배열 내 전송의 순서(["internal", "hybrid"] 대 ["hybrid", "internal"])는 플랫폼 및 인증기 구현에 따라 다르지만 기능적인 차이는 없습니다. 둘 다 동일한 전송 방법에 대한 지원을 나타냅니다.

레거시 용어: cable 전송 식별자는 구형 구현에서 가끔 나타나며 hybrid와 동의어입니다(caBLE = 클라우드 지원 Bluetooth Low Energy, 하이브리드 전송의 원래 이름).

이러한 분포는 internal 및 hybrid 전송을 올바르게 처리하는 것의 중요성을 강화하며, 실제 패스키 구현의 압도적 다수를 차지하기 때문입니다.

전송 가용성은 결과 흐름이 완료되는지 여부가 아니라 인증기가 보고하는 내용을 보여줍니다. Corbado 패스키 벤치마크 2026 교차 기기 인증 완료율 분석에 따르면, 2026년 1분기 hybrid 전송 완료율은 전반적으로 Windows 웹에서 6078%, macOS 웹에서 6686%로 측정되며, 동일 기기 유도의 경우 7998%(Win) / 8398%(macOS), 식별자 우선 흐름의 경우 5267%(Win) / 5976%(macOS)로 나뉩니다. 라우팅 로직에서 hybrid를 가장 비용이 많이 드는 전송으로 취급하고 크리덴셜을 보유한 기기에 사용자를 유지하는 흐름을 선호하십시오.

동일한 인증기가 플랫폼, 버전 및 구현 컨텍스트에 따라 다른 전송 패턴을 보고하는 경우가 많습니다. 이러한 변화는 정상적이고 예상되는 현상입니다.

iCloud Keychain은 세 가지 패턴을 보입니다.

• ["internal", "hybrid"] - 웹 브라우저에서 가장 흔함
• [] (빈 배열) - iOS 네이티브 앱에서 매우 흔함
• ["hybrid", "internal"] - 덜 흔함, 순서 변형
• ["internal"] 또는 ["hybrid"] 단독 - 드문 엣지 케이스

Google Password Manager는 가장 큰 변동을 보입니다.

• ["hybrid", "internal"] - 가장 흔한 패턴
• ["internal", "hybrid"] - 흔한 대체 순서
• ["internal", "cable"] - 레거시 구현 (cable = 하이브리드의 이전 용어)
• [] (빈 배열) - 특정 네이티브 컨텍스트에서 발생
• 단일 전송은 드묾

Windows Hello가 가장 일관적입니다.

• ["internal"] - 지배적인 패턴 (설계상 기기 종속적)

1Password, Bitwarden, Dashlane 및 LastPass와 같은 비밀번호 관리자는 모두 유사한 변동 패턴을 보입니다.

• ["internal", "hybrid"] 및 ["hybrid", "internal"] 순서 모두
• 네이티브 앱 컨텍스트에서 빈 배열 []
• 가끔 ["internal"]만 존재

Samsung Pass (Android 에코시스템)는 주로 다음을 사용합니다.

• ["hybrid", "internal"] 및 ["internal", "hybrid"] - 두 순서 모두 흔함

플랫폼 차이: 동일한 인증기가 웹 대 네이티브, iOS 대 Android, Windows 대 macOS에서 다르게 동작합니다.

버전 진화: 전송 보고는 시간이 지남에 따라 진화했습니다. 이전 버전은 hybrid 대신 cable을 사용하거나 다른 조합을 보고할 수 있습니다.

구현 선택: 일부 인증기는 internal을 우선하고 다른 인증기는 hybrid를 우선합니다. 순서는 기능에 영향을 미치지 않지만 구현에 따라 다릅니다.

컨텍스트 민감도: 특히 iOS의 네이티브 앱은 웹 컨텍스트에서 전체 전송을 보고하는 인증기에서도 빈 배열을 수신하는 경우가 많습니다.

핵심 요약: 특정 인증기에 대한 전송 배열이 일관될 것이라고 가정하지 마십시오. 정확한 배열 일치보다는 특정 전송의 존재에 초점을 맞춰 모든 변형을 우아하게 처리하도록 구현을 설계하십시오.

개발자는 사양을 엄격하게 따를지, 아니면 사용자 경험을 위해 내부 및 하이브리드 전송을 최적화할지 선택해야 합니다. 각 접근 방식에는 장단점이 있습니다.

이 접근 방식은 WebAuthn 사양과 일치합니다. 크리덴셜 등록 중에 인증기에서 제공하는 그대로 전송을 사용하고, 인증 중에 변경 없이 다시 전송합니다.

구현: 패스키가 생성되면 인증기 응답의 transports 배열을 유지합니다. 인증하는 동안 allowCredentials 목록에 이 정확한 전송을 포함합니다.

{
    "allowCredentials": [
        {
            "id": "credential-id-base64",
            "type": "public-key",
            "transports": ["internal", "hybrid"]
        }
    ]
}

장점:

• 사양 준수: WebAuthn 표준을 정확히 따라 향후 플랫폼 업데이트와의 호환성 보장
• 보안 키 안정성: 항상 정확한 전송 정보를 제공하는 하드웨어 보안 키(YubiKey 등)에 완벽하게 작동
• 잘못된 옵션 방지: 실제로 지원되지 않는 인증 방법을 제공하는 것을 피함—예를 들어 Windows Hello 크리덴셜에 대한 QR 코드를 트리거하지 않음

단점:

• iOS의 빈 배열 동작: iOS의 플랫폼 인증기는 빈 전송을 반환하는데, 이는 사용할 수 없는 전송 정보를 나타내며 플랫폼은 어떤 인증 옵션을 표시할지 결정할 때 이를 다르게 해석할 수 있음
• 원치 않는 옵션 표시 가능성: 소비자 애플리케이션에서 예상치 못한 보안 키 옵션(USB, NFC)을 제시할 수 있음
• 일관성 없는 사용자 경험: 다른 플랫폼이 동일한 계정에 대해 다른 인증 옵션을 제공함

적합한 대상: 표준 준수를 우선시하는 애플리케이션, 다양한 인증기 유형을 갖춘 엔터프라이즈 환경.

이 접근 방식은 특정 최적화 목표에 따라 내부 및 하이브리드 전송을 선택적으로 수정하여 사용자 경험을 우선시합니다. 일괄적인 규칙보다는 다음과 같은 일반적인 최적화 시나리오를 고려해 보십시오.

문제: iOS 플랫폼 인증기는 빈 전송 배열을 반환합니다. 비워 두거나 백엔드에서 채우면, 소비자가 애플리케이션에서 플랫폼 옵션과 함께 보안 키 프롬프트(USB, NFC)를 보게 되어 혼란을 초래할 수 있습니다.

해결책: iOS 플랫폼 인증기에 대해 전송을 명시적으로 ["hybrid", "internal"]로 설정합니다. 이렇게 하면 보안 키 옵션을 숨기고 플랫폼 인증 및 교차 기기 흐름만 제공되도록 할 수 있습니다.

// iOS 플랫폼 인증기 크리덴셜을 유지할 때
if (platform === "iOS" && authenticatorAttachment === "platform") {
    transports = ["hybrid", "internal"];
}

결과: iOS 생성 패스키에 대한 보안 키 프롬프트가 없는 깔끔한 인증 UI.

문제: 모바일 기기에서 인증할 때 교차 기기 인증용 QR 코드를 표시하면 좋지 않은 UX가 생성됩니다. 사용자는 이미 자신의 패스키를 사용할 수 있는 모바일 기기를 사용하고 있기 때문입니다.

해결책: 사용자가 모바일 기기에서 인증할 때 hybrid 전송을 제거하여 ["internal"]만 남깁니다.

// 인증을 위한 allowCredentials를 구축할 때
const transports = isMobileDevice
    ? credentials.transports.filter((t) => t !== "hybrid")
    : credentials.transports;

결과: 모바일 사용자는 불필요한 QR 코드 프롬프트 없이 직접 인증 옵션만 볼 수 있습니다.

⚠️ 주의: 전송 조작이 플랫폼 전반에서 항상 일관된 결과를 내는 것은 아닙니다. 광범위한 테스트에 따르면 브라우저 및 OS 조합에 따라 전송을 다르게 처리합니다.

• 일부 플랫폼은 전송에서 hybrid를 제외해도 여전히 QR 코드를 표시합니다.
• 다른 플랫폼은 hybrid가 포함되어 있어도 QR 코드를 숨깁니다.
• 동작은 Windows, macOS 및 iOS 환경에서 Chrome, Edge, Safari 및 Firefox 간에 크게 다릅니다.

데드엔드 위험: 지나치게 제한적인 전송 필터링은 사용자가 전혀 로그인할 수 없는 인증 데드엔드를 만들 수 있습니다. 예를 들어, hybrid를 제거하면 사용자가 빌린 기기에서 인증해야 하는 합법적인 교차 기기 인증 시나리오가 차단될 수 있습니다. 전송 최적화를 배포하기 전에 항상 타겟 플랫폼 전반에서 철저히 테스트하고 예비 인증 방법을 제공하십시오.

이것은 최적화 힌트입니다: WebAuthn은 전송 조작 외에도 힌트와 같은 인증 UX 최적화를 위한 다른 메커니즘을 제공합니다.

전송 동작은 예측할 수 없습니다: hybrid 전송을 통한 교차 기기 인증(CDA)은 브라우저 및 OS 조합에 따라 일관성 없는 동작을 보입니다. 실제 테스트에 따르면 전송 값이 특정 UI 동작을 보장하지 않습니다. 플랫폼은 전송을 다르게 해석하고 처리하여 예상치 못한 결과를 초래합니다.

플랫폼별 복잡성: 전송을 명시적으로 제어할 때, 플랫폼 차이를 고려해야 합니다.

• iOS: 플랫폼 인증기에 대해 빈 배열을 보냅니다. 값을 채워야 합니다.
• Windows Hello: 반드시 ["internal"] 전용이어야 합니다. hybrid를 추가하면 원치 않는 QR 코드가 트리거됩니다.
• 웹 및 Android: 일반적으로 정확한 전송 정보를 제공합니다.
• CDA 변형: 전송 배열에 hybrid가 존재하는지 여부와 관계없이 QR 코드 프롬프트가 나타나거나 사라질 수 있습니다.

엔드투엔드 이해 필요: 명시적으로 전송을 제어한다는 것은 전체 흐름에 대한 책임을 진다는 의미입니다. 각 전송 조합이 모든 타겟 플랫폼에서 어떻게 동작하는지 이해하고 철저히 테스트해야 합니다. 전송 조작은 사용자를 위한 유효한 인증 경로가 없는 인증 데드엔드를 만들 수 있습니다.

장점:

• 맞춤형 UX: 특정 컨텍스트에서 사용자가 볼 수 있는 인증 옵션을 정확하게 제어
• iOS 빈 배열 문제 해결: iOS가 제공하지 않는 전송을 명시적으로 정의
• 컨텍스트 인지 최적화: 기기 유형에 따라 인증 UI 조정

단점:

• 예측할 수 없는 동작: 전송 조작이 일관된 UI 동작을 보장하지 않음—광범위한 테스트에 따르면 플랫폼은 전송을 다르게 해석하며, 전송 값과 무관하게 옵션을 표시하거나 숨기기도 함
• 인증 데드엔드 위험: 지나치게 제한적인 전송 필터링은 특히 교차 기기 시나리오에서 사용자의 인증을 완전히 차단할 수 있음
• 사양에서 벗어남: 사양 권장 사항에서 벗어나 향후 플랫폼 변경 시 문제를 일으킬 수 있음
• 유지보수 부담: 플랫폼이 발전함에 따라 지속적인 플랫폼별 로직 및 업데이트 필요
• 복잡성: iOS 빈 배열, Windows Hello 제약 조건 및 기타 플랫폼의 특이성을 수동으로 처리해야 함
• 테스트 오버헤드: 모든 최적화 규칙은 모든 플랫폼 조합에서 검증이 필요함

적합한 대상: 특정 UX 요구 사항이 있는 소비자 애플리케이션, 플랫폼별 로직을 유지할 수 있는 리소스가 있는 팀, 엄격한 사양 준수보다 간소화된 인증 흐름을 우선시하는 시나리오.

WebAuthn 전송 처리는 독자적으로 존재하지 않으며 전체 패스키 구현 전략의 한 부분입니다. 프로덕션 배포에서 나타나는 두 가지 일반적인 접근 방식은 각각 내부 및 하이브리드 전송 사용에 다른 의미를 갖습니다.

이 접근 방식은 사용자가 호환 가능한 모든 인증기로 인증할 수 있도록 허용하며 유연성과 표준 준수를 우선시합니다.

구현 특징:

• 인증 UI: 패스키 버튼이 기존 로그인 옵션(사용자 이름/비밀번호)과 함께 표시됨
• allowCredentials: 빈 배열 []로 설정되어 모든 크리덴셜이 일치하도록 허용
• 인증기 유형: 보안 키, 교차 기기 인증(QR 코드), 플랫폼 인증기 모두 지원
• 네이티브 앱 요구 사항: 보안 키를 포함한 모든 인증 방법을 지원해야 함
• preferImmediatelyAvailableCredentials: 정의상 보안 키와 QR 코드 로그인을 제외하므로 사용할 수 없음
• 전송 처리: 보안 키 전송(usb, nfc, ble)을 포함한 모든 전송 유형을 수용해야 함

전송의 영향:

비어 있는 allowCredentials를 사용하면 인증 중 전송의 중요성이 떨어지며, 플랫폼이 사용 가능한 모든 옵션을 표시합니다. 하지만 이는 사용자가 보안 키 프롬프트, QR 코드 및 플랫폼 옵션을 동시에 볼 수 있음을 의미하며 소비자 애플리케이션에서는 결정 마비를 일으킬 수 있습니다.

적합한 대상: 엔터프라이즈 환경, 보안 키 지원이 필요한 다양한 사용자 기반이 있는 애플리케이션, 최대한의 인증 유연성을 우선시하는 시나리오.

이 접근 방식은 패스키 생성을 플랫폼 인증기로 제한하고 식별자 우선 흐름을 사용하여 소비자 UX를 최적화합니다.

구현 특징:

• 패스키 생성: 사용자 시작 유도(로그인 후 프롬프트, 자동 생성 흐름)는 authenticatorAttachment: "platform"을 사용하여 즉시 사용 가능한 인증기에 초점을 맞춤
• 보안 키 지원: authenticatorAttachment 제한 없이 웹 계정 설정을 통해 사용할 수 있어 파워 유저가 보안 키를 포함한 모든 인증기를 선택할 수 있음
• 인증 흐름: 식별자 우선—사용자는 인증 전에 이메일/사용자 이름을 입력
• allowCredentials: 식별자가 알려지면 사용자의 특정 크리덴셜로 채워짐(비어 있지 않음)
• 인증기 유형: 플랫폼 인증기 및 교차 기기 인증을 우선시. 보안 키는 지원되지만 기본 흐름에서는 장려하지 않음
• 네이티브 앱 최적화: 보안 키나 QR 코드에 대한 프롬프트 없이 조용하고 즉각적인 인증을 위해 preferImmediatelyAvailableCredentials 사용
• 교차 기기 인증: 웹에서는 사용 가능하지만, preferImmediatelyAvailableCredentials를 사용할 때 네이티브 앱에서는 의도적으로 제외됨(사용자는 보통 패스키가 있는 기기에서 인증함)
• 전송 처리: internal 및 hybrid 전송에 주로 초점

전송의 영향:

allowCredentials에 특정 크리덴셜과 그 전송 정보가 포함되므로 전송 처리는 인증 경험을 최적화하는 데 중요해집니다.

보안 키의 현실: 대규모 소비자 배포에서 보안 키는 패스키 사용의 극히 작은 부분을 차지하며 주로 파워 유저나 특정 보안 요구 사항이 있는 사용자가 씁니다. 소비자 맞춤형 접근 방식은 기본 흐름을 보안 키에 맞추지 않으면서도 이를 지원함으로써 이런 현실을 반영합니다.

이중 계층 생성 전략: 구현 시 다음의 이중 생성 경로를 통해 소비자 UX를 최적화하면서 보안 키 호환성의 균형을 맞출 수 있습니다.

• 사용자 유도 및 프롬프트: 로그인 후 프롬프트 및 자동 생성 흐름은 authenticatorAttachment: "platform"을 사용하여 높은 성공률로 즉시 사용할 수 있는 패스키로 사용자를 안내합니다.
• 웹 계정 설정: authenticatorAttachment 없이 생성을 제공하여 파워 유저가 보안 키, 타사 비밀번호 관리자 또는 사용 가능한 모든 인증기를 선택할 수 있도록 합니다.

이러한 패턴은 주요 구현에서 나타납니다. 설정을 통해 보안 키가 지원되고 기능하지만, 사용자 대상 유도는 즉각적이고 조용한 인증을 제공하는 플랫폼 인증기라는 지배적인 사용 사례를 최적화합니다.

적합한 대상: 소비자 애플리케이션, 네이티브 모바일 앱, 인증기 유연성보다 간소화된 UX를 우선시하는 시나리오, 이미 식별자 우선 흐름이 있는 플랫폼.

계정 존재를 이미 노출하거나 식별자 우선 흐름(사용자가 로그인 옵션을 보기 전에 이메일 입력)을 사용하는 플랫폼의 경우 소비자 맞춤형 접근 방식이 자연스럽게 일치합니다. 사용자가 식별자를 제공하면:

1. 백엔드가 기존 패스키를 쿼리합니다.
2. 특정 크리덴셜과 해당 전송이 포함된 allowCredentials를 반환합니다.
3. 플랫폼은 전송에 따라 인증 UI를 최적화할 수 있습니다.
4. 추가적인 계정 열거 위험이 없습니다(식별자가 이미 제공됨).

이러한 시나리오에서 전송은 보안 문제가 아니라 최적화 도구가 될 수 있습니다. 기기 컨텍스트(모바일 대 데스크톱) 및 크리덴셜 기능에 따라 인증 옵션을 맞춤 설정할 수 있습니다.

권장 사항: 이미 식별자 우선 흐름을 사용하거나 계정 열거가 문제가 되지 않는 플랫폼의 경우 명시적인 전송 처리를 갖춘 소비자 맞춤형 접근 방식이 뛰어난 UX를 제공합니다. 특히 preferImmediatelyAvailableCredentials를 통해 원활한 생체 인식을 지원하는 네이티브 모바일 애플리케이션에서 유용합니다.

내부 및 하이브리드 전송을 처리하기 위해 어떤 접근 방식을 선택하든 문제를 최소화하려면 다음 사례를 따르십시오.

등록 중 전송 유지: 항상 인증기 응답에서 얻은 transports 배열을 크리덴셜 ID 및 공개 키와 함께 저장하십시오. 이 데이터는 인증 흐름에 필수적입니다.

빈 배열을 우아하게 처리: iOS 플랫폼 인증기에서 빈 전송 배열을 수신하는 경우:

• 사양 준수: 비워 두거나 전송 속성을 생략—전송 정보를 사용할 수 없음을 나타내며 플랫폼이 사용 가능한 옵션을 결정합니다.
• 최적화 접근 방식: ["internal", "hybrid"]로 채워 표시되는 인증 옵션을 제어합니다.

웹 대 네이티브 전송 전략: 컨텍스트에 따라 전송 처리를 다르게 하십시오.

• 웹 인증: 모든 전송을 포함하여 USB/NFC를 통한 보안 키를 포함해 더 광범위한 인증기 지원을 허용합니다.
• 네이티브 앱 인증: 조용한 인증을 위해 preferImmediatelyAvailableCredentials를 사용합니다. 전송은 저장된 대로 보냅니다.
• 설정/관리 페이지: 파워 유저를 위해 모든 인증기 유형을 지원합니다.

보안 키 인증 처리: 사용자가 보안 키를 등록한 경우:

• 웹: 저장된 크리덴셜에서 보안 키 전송을 감지하고 인증 흐름이 이를 수용할 수 있는지 확인합니다.
• 네이티브 앱: 대체 인증 방법을 제공하거나 사용자를 보안 키 인증을 위한 웹으로 유도하는 것을 고려합니다.
• 하이브리드 접근 방식: 네이티브 앱은 플랫폼 인증기에 맞게 최적화하는 반면 웹은 완벽한 인증기 유연성을 지원합니다.

모든 타겟 플랫폼에서 테스트: 모든 조합을 포괄하는 테스트 매트릭스를 만듭니다.

• 등록: 웹, iOS 네이티브, Android 네이티브
• 인증: 웹, iOS 네이티브, Android 네이티브
• preferImmediatelyAvailableCredentials에서 조용한 인증이 작동하는지 확인
• authenticatorAttachment가 없는 설정 흐름에서 보안 키가 작동하는지 확인
• QR 코드가 적절한 컨텍스트에서만 나타나는지 검증

전송 의미론 이해: 빈 전송 값과 누락된 전송 값의 차이점을 인식합니다.

• 빈 전송 배열 []: 전송 정보를 사용할 수 없거나 개인정보 보호를 위해 보류되었음을 나타냅니다. 사용자 에이전트는 전송 기능을 보고할 수 없거나 보고하지 않기로 선택할 때 빈 시퀀스를 제공할 수 있습니다. 이는 "모든 전송이 지원됨"을 뜻하지 않으며 정보가 없는 경우 힌트로 취급합니다.
• 누락된 전송 속성: 크리덴셜 디스크립터에서 전송이 생략되면 사용자 에이전트는 다른 요소를 기반으로 사용 가능한 인증 방법을 결정합니다. 컨텍스트가 중요합니다. 등록 응답과 인증 요청 옵션에서의 의미는 서로 다릅니다.
• 전송 힌트: 사양에 따라 전송은 인증 UI를 최적화하도록 사용자 에이전트를 돕는 힌트로 취급해야 하며, 권위 있는 기능 보장으로 취급해서는 안 됩니다.

플랫폼 변경 사항 모니터링: WebAuthn 구현은 진화합니다. Apple, Google 및 Microsoft는 정기적으로 인증기 동작을 업데이트합니다. 전송 처리에 영향을 줄 수 있는 변경 사항에 대해 계속 정보를 얻으십시오.

WebAuthn 전송, 특히 내부 및 하이브리드 전송은 교차 기기 인증에 실제적이고 중대한 영향을 미치는 기술적 세부 사항입니다. 전송 처리 전략은 전반적인 패스키 구현 접근 방식 및 타겟 플랫폼과 일치해야 합니다.

전송 결정은 광범위한 전략 내에 존재합니다: 전송 처리 방법은 최대의 유연성을 위해(빈 allowCredentials) 구축할 것인지 또는 소비자 UX(특정 크리덴셜이 있는 식별자 우선)를 위해 구축할 것인지에 따라 달라집니다. 후자의 경우 전송이 최적화에 매우 중요합니다.

플랫폼 차이 처리 필요: 웹과 Android는 신뢰할 수 있는 전송 정보를 제공하지만, iOS 플랫폼 인증기는 빈 배열을 반환합니다. Windows Hello는 ["internal"]만 보냅니다. 프로덕션 배포에는 이러한 차이를 이해하는 것이 필수적입니다.

두 가지 유효한 전송 접근 방식: 사양 준수(인증기 전송 신뢰)는 엔터프라이즈 및 최대한의 유연성 시나리오에 적합합니다. 명시적 제어(전송 최적화)는 식별자 우선 흐름 및 네이티브 모바일 앱이 있는 소비자 애플리케이션에 적합합니다.

식별자 우선을 통해 전송 최적화 가능: 사용자가 자신의 식별자를 먼저 제공하면 전송 처리는 강력한 UX 도구가 됩니다. 추가적인 계정 열거 우려 없이 모바일에서 원치 않는 QR 코드를 방지하고, 보안 키 옵션을 숨기며, 인증을 간소화할 수 있습니다.

엔터프라이즈 / 최대한의 유연성을 위해:

• 비어 있는 allowCredentials를 사용하여 모든 인증기 유형 지원
• 인증기에서 제공하는 전송 신뢰
• 사용자가 더 많은 인증 옵션을 보는 것을 허용
• 구현이 더 간단하고 호환성이 넓음

소비자 애플리케이션 / 네이티브 앱을 위해:

• 식별자 우선 인증 흐름 구현
• 사용자 유도(로그인 후, 자동 프롬프트): 높은 성공률의 즉각적인 인증을 위해 authenticatorAttachment: "platform" 사용
• 웹 계정 설정: 보안 키가 필요한 파워 유저를 위해 authenticatorAttachment 없이 생성 허용
• 특정 크리덴셜과 최적화된 전송 정보가 있는 allowCredentials 사용
• 네이티브 앱: 조용한 인증을 위해 preferImmediatelyAvailableCredentials 활성화
• iOS의 빈 배열을 ["hybrid", "internal"]로 채움
• 웹 인증: 보안 키를 포함한 모든 전송 지원
• 적절한 경우 모바일 기기에서 hybrid를 필터링하여 QR 코드 방지
• 호환성을 유지하면서 간소화된 인증 옵션으로 뛰어난 UX 제공

이미 식별자 우선 흐름이 있는 플랫폼의 경우:

• 계정 열거가 이미 문제 되지 않음
• 소비자 맞춤형 접근 방식은 기존 UX와 자연스럽게 일치
• 전송 최적화가 즉각적인 UX 혜택을 제공
• 대부분의 소비자 애플리케이션을 위한 권장 접근 방식

사양 준수로 시작하고 전략에 따라 최적화하십시오.

1. 등록 중에 수신된 전송을 정확히 유지
2. 전반적인 전략 결정(최대 유연성 대 소비자 맞춤형)
3. 소비자 맞춤형인 경우: 식별자 우선 흐름을 구현하고 전송 최적화
4. 선택한 전략에 맞게 iOS의 빈 배열을 적절히 처리
5. 웹, iOS 네이티브 및 Android 네이티브 플랫폼 전반에서 철저히 테스트

WebAuthn 환경은 계속 진화하고 있습니다. 플랫폼 공급업체는 정기적으로 구현을 업데이트하며, WebAuthn 레벨 3와 같은 사양은 새로운 기능을 도입합니다. 전송 처리를 폭넓은 인증 전략과 일치시키는 유연한 시스템을 구축하면 패스키 구현이 견고하게 유지되고 생태계가 성숙함에 따라 탁월한 사용자 경험을 제공할 수 있습니다.

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 전문가와 상담하기 →

iOS AuthenticationServices는 iCloud Keychain과 같은 플랫폼 인증기에 대한 전송 정보를 보류하여 WebAuthn 사양의 개인정보 보호 조항에 따라 빈 배열을 반환합니다. iOS의 보안 키는 ["usb"] 또는 ["nfc"]와 같은 전송 데이터를 제공합니다. 신뢰 당사자는 모든 전송을 권위 있는 기능 보장이 아닌 힌트로 취급해야 합니다.

cable은 hybrid와 동의어인 레거시 용어이며 caBLE(클라우드 지원 Bluetooth Low Energy)의 약자입니다. 둘 다 휴대폰을 사용하여 데스크톱 세션을 인증하기 위해 QR 코드를 스캔하는 것과 같은 교차 기기 인증을 설명합니다. hybrid는 WebAuthn 레벨 3에 도입된 최신 용어이며 새로운 구현에서 사용되어야 합니다.

식별자 우선 흐름을 사용하는 소비자 애플리케이션의 경우 등록 중 빈 배열을 반환한 iOS 플랫폼 인증기에 대해 전송을 명시적으로 ["hybrid", "internal"]로 설정하십시오. 이렇게 하면 인증 UI에 USB 및 NFC 보안 키 프롬프트가 나타나지 않습니다. 사양을 준수하는 대안은 배열을 비워 두거나 전송 속성을 아예 생략하는 것입니다.

모바일에서 hybrid 전송을 제거하면 사용자가 자신의 패스키가 있는 기기에 이미 접속해 있을 때 QR 코드 프롬프트를 방지할 수 있습니다. 그러나 전송 조작은 일관성 없는 결과를 낳습니다. 일부 플랫폼은 hybrid를 제외해도 QR 코드를 표시하고, 다른 플랫폼은 이와 무관하게 QR 코드를 숨깁니다. 데드엔드가 생기지 않게 하려면 항상 타겟 플랫폼에서 테스트하고 대체 인증 방법을 제공하십시오.

비어 있는 allowCredentials 배열은 보안 키와 교차 기기 인증을 포함한 모든 인증기 유형을 지원하지만 전송의 관련성을 낮추어 사용자에게 여러 옵션을 동시에 제시할 수 있습니다. 특정 사용자 크리덴셜로 이를 채우면 전송 처리가 UI 최적화에 중요해져 식별자 우선 흐름이 모바일에서 QR 코드를 필터링하고 소비자 컨텍스트에서 보안 키 프롬프트를 숨길 수 있게 됩니다.