WebAuthn 전송 방식: 내부 및 하이브리드 전송 알아보기

Passkeys for Super Funds and Financial Institutions
Join our Webinar on 7th November to learn how Super Funds and Financial Institutions can implement passkeys

Join now

참고: WebAuthn 사양에 따르면, 전송 방식이 비어 있는 것은 모든 전송 방식을 지원한다는 의미입니다.

여러 플랫폼에 걸쳐 패스키를 구현할 때 개발자들은 중요한 결정에 직면합니다.

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

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

이 글에서는 여러 플랫폼에서 WebAuthn 전송 방식이 어떻게 작동하는지 살펴보고, 내부 및 하이브리드 전송 방식을 처리하는 두 가지 다른 접근법과 각각의 장단점을 제시합니다.

이 글에서 다루는 내용:

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

WebAuthn 전송 방식은 인증자와 클라이언트 기기 간의 통신 방법을 정의합니다. WebAuthn Level 3 사양에서는 여섯 가지 전송 유형을 정의합니다.

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

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

ble: 블루투스 저전력(Energy)을 통한 인증을 용이하게 하여 외부 인증자와의 무선 통신을 가능하게 합니다.

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

hybrid: 사용자가 QR 코드를 스캔하여 기기 간에 인증하는 경우와 같이 기기 간 인증을 가능하게 합니다. 예를 들어, 휴대폰을 사용하여 데스크톱 브라우저에서 인증하거나 그 반대의 경우입니다. 이 전송 방식은 데스크톱과 모바일 기기 모두에서 QR 코드 프롬프트를 트리거할 수 있으며, 이는 상황에 따라 항상 바람직하지는 않을 수 있습니다. 참고: hybrid는 WebAuthn Level 3에서 추가되었습니다.

internal: 인증자가 기기 자체에 내장된 경우입니다. 예를 들어 iPhone의 iCloud 키체인(Face ID 또는 Touch ID로 확인), PC의 Windows Hello, Android 기기의 Google 비밀번호 관리자 등이 있습니다. 이들은 플랫폼 인증자입니다.

패스키가 생성될 때, 인증자는 지원하는 전송 방식을 신호로 보냅니다. 이 정보는 신뢰 당사자(백엔드)로 전송되며, 백엔드는 이를 자격 증명과 함께 저장해야 합니다. 인증 중에 신뢰 당사자는 이 전송 방식들을 allowCredentials 목록에 담아 클라이언트로 다시 보내고, 브라우저나 플랫폼이 사용자에게 어떤 인증 방법을 제공할지 결정하는 데 도움을 줍니다.

전송 방식 처리는 플랫폼마다 크게 달라 개발자들이 호환성 문제에 직면하게 만듭니다.

브라우저는 인증자로부터 전송 방식 정보를 받아 인증 흐름 중에 이를 존중합니다. Chrome, Safari 또는 Edge에서 패스키를 생성하면 브라우저의 자격 증명 관리자는 기본 인증자에 따라 달라지는 전송 데이터를 제공합니다.

플랫폼 인증자: Windows Hello는 기기 종속적인 특성을 반영하여 ["internal"]만 제공합니다. 하지만 Chrome이 Google 비밀번호 관리자를 인증자로 사용할 때는 Google 비밀번호 관리자가 Android 휴대폰을 통한 기기 간 인증을 지원하기 때문에 ["internal", "hybrid"]를 제공합니다.

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

클라우드 동기화 자격 증명 관리자: Safari의 iCloud 키체인과 Chrome의 Google 비밀번호 관리자는 일반적으로 로컬 및 기기 간 인증 흐름을 모두 지원하기 위해 ["internal", "hybrid"]를 제공합니다.

이 정보는 웹 컨텍스트에서는 안정적으로 흐르지만, 특정 전송 방식은 브라우저가 자격 증명 저장소로 어떤 인증자를 선택하느냐에 따라 달라집니다.

문서: W3C WebAuthn Specification

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

문서: Android Credential Manager

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

플랫폼 인증자(iCloud 키체인, Face ID 또는 Touch ID로 확인): 패스키 생성 중에 종종 빈 전송 배열을 반환합니다. 이것이 패스키에 전송 기능이 없다는 의미는 아닙니다. 단지 iOS가 명시적으로 보고하지 않는다는 뜻입니다. WebAuthn 표준에 따르면 전송 방식을 생략하는 것은 모든 전송 방식이 허용된다는 의미이므로 하이브리드 인증은 여전히 작동합니다.

보안 키: iOS 기기와 함께 사용할 경우 예상대로 전송 정보(예: ["usb"], ["nfc"])를 제공합니다.

문서: Apple AuthenticationServices

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

이 접근법은 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"을 통해 플랫폼 인증자만 허용됩니다.
• 인증 흐름: 식별자 우선 - 사용자는 인증 전에 이메일/사용자 이름을 입력합니다.
• allowCredentials: 식별자가 알려지면 사용자의 특정 자격 증명으로 채워집니다(비어 있지 않음).
• 인증자 유형: 플랫폼 인증자 및 기기 간 인증. 보안 키는 일반적으로 제외됩니다.
• 네이티브 앱 최적화: preferImmediatelyAvailableCredentials를 사용할 수 있으며, 이는 정의상 보안 키와 기기 간 인증을 제외합니다.
• 기기 간 인증: 웹에서는 사용 가능. 네이티브 앱에서 preferImmediatelyAvailableCredentials를 사용할 때는 사용할 수 없지만, 이 시나리오는 드뭅니다(사용자는 일반적으로 사용 중인 기기에 패스키를 가지고 있음).
• 전송 방식 처리: internal 및 hybrid 전송 방식에만 초점을 맞춥니다.

전송 방식에 미치는 영향:

allowCredentials에 특정 자격 증명과 그 전송 방식이 포함되므로 전송 방식 처리가 중요해집니다.

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

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

1. 백엔드가 기존 패스키를 조회합니다.
2. 특정 자격 증명과 그 전송 방식을 포함한 allowCredentials를 반환합니다.
3. 플랫폼은 전송 방식을 기반으로 인증 UI를 최적화할 수 있습니다.
4. 추가적인 계정 열거 위험이 없습니다(식별자가 이미 제공되었기 때문).

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

권장 사항: 이미 식별자 우선 흐름을 사용하거나 계정 열거가 우려되지 않는 플랫폼의 경우, 명시적인 전송 방식 처리를 통한 소비자에 맞춘 접근법이 우수한 UX를 제공합니다. 특히 preferImmediatelyAvailableCredentials가 원활한 생체 인증을 가능하게 하는 네이티브 모바일 애플리케이션에서 더욱 그렇습니다.

내부 및 하이브리드 전송 방식을 처리하기 위해 어떤 접근법을 선택하든, 다음 관행을 따르면 문제를 최소화할 수 있습니다.

등록 시 전송 방식 저장: 항상 인증자 응답의 transports 배열을 자격 증명 ID 및 공개 키와 함께 저장하세요. 이 데이터는 인증 흐름에 필수적입니다.

빈 배열을 적절히 처리: iOS 플랫폼 인증자로부터 빈 전송 배열을 받을 때:

• 사양 준수: 비워두거나 transports 속성을 생략합니다. 이는 "모든 전송 방식이 허용됨"을 의미합니다.
• 최적화 접근법: ["internal", "hybrid"]로 채워서 어떤 인증 옵션이 표시될지 제어합니다.

모든 대상 플랫폼에서 테스트: 다음 조합을 모두 포함하는 테스트 매트릭스를 만드세요.

• 등록: 웹, iOS 네이티브, Android 네이티브
• 인증: 웹, iOS 네이티브, Android 네이티브
• QR 코드가 예상될 때 나타나고 부적절할 때 숨겨지는지 확인합니다.

빈 배열 vs. 누락된 속성 이해: 빈 전송 배열 []과 누락된 transports 속성 모두 일반적으로 사양에 따라 "모든 전송 방식이 허용됨"으로 처리됩니다. 그러나 구현 세부 사항은 플랫폼마다 다릅니다.

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

WebAuthn 전송 방식, 특히 내부 및 하이브리드 전송 방식은 기기 간 인증에 상당한 실질적 영향을 미치는 기술적 세부 사항입니다. 전송 방식 처리 전략은 더 넓은 패스키 구현 접근법과 대상 플랫폼에 부합해야 합니다.

전송 방식 결정은 더 넓은 전략 내에 존재합니다: 전송 방식을 처리하는 방법은 최대 유연성(빈 allowCredentials)을 위해 구축하는지, 아니면 소비자 UX(식별자 우선 및 특정 자격 증명)를 위해 구축하는지에 따라 달라집니다. 후자의 경우 전송 방식이 최적화에 중요해집니다.

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

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

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

기업 / 최대 유연성을 위해:

• 모든 인증자 유형을 지원하기 위해 빈 allowCredentials를 사용합니다.
• 인증자가 제공한 전송 방식을 신뢰합니다.
• 사용자가 더 많은 인증 옵션을 보게 되는 것을 수용합니다.
• 더 간단한 구현, 더 넓은 호환성.

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

• 식별자 우선 인증 흐름을 구현합니다.
• 플랫폼 인증자로 제한합니다(authenticatorAttachment: "platform").
• 특정 자격 증명과 최적화된 전송 방식을 포함한 allowCredentials를 사용합니다.
• 네이티브 앱에서 preferImmediatelyAvailableCredentials를 활성화합니다.
• iOS 빈 배열을 ["hybrid", "internal"]로 채웁니다.
• 모바일 기기에서 hybrid를 필터링하여 QR 코드를 방지합니다.
• 간소화된 인증 옵션으로 우수한 UX.

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

• 계정 열거는 이미 문제가 되지 않습니다.
• 소비자에 맞춘 접근법이 기존 UX와 자연스럽게 어울립니다.
• 전송 방식 최적화는 즉각적인 UX 이점을 제공합니다.
• 대부분의 소비재 애플리케이션에 권장되는 접근법입니다.

사양 준수로 시작한 다음 전략에 따라 최적화하세요:

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

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