패스키가 QR 코드와 블루투스를 활용하여 어떻게 크로스 플랫폼 인증을 구현하고, 비밀번호 없이 여러 기기에서 원활하고 안전한 로그인을 가능하게 하는지 알아보세요.
Vincent
Created: July 1, 2025
Updated: July 8, 2025
See the original blog version in English here.
Our mission is to make the Internet a safer place, and the new login standard passkeys provides a superior solution to achieve that. That's why we want to help you understand passkeys and its characteristics better.
패스키는 사용자 인증의 사실상 표준으로 점차 비밀번호를 대체하고 있습니다. 기존 비밀번호와 달리 패스키는 특정 생태계(예: iCloud 키체인, Google 비밀번호 관리자, Windows Hello 또는 1Password나 Dashlane과 같은 비밀번호 관리자)에 종속됩니다. 패스키는 암기하도록 설계된 것이 아니라, 기기와 원활하게 통합되어 기본적으로 훌륭한 사용자 경험을 제공하도록 만들어졌습니다.
개인 컴퓨터가 아닌 공용 터미널이나 친구의 노트북에서 패스키로 보호된 계정에 로그인해야 하는 상황을 상상해 보세요. 이 시나리오는 매우 흔하며 안전하면서도 편리한 인증 방법이 필요하지만, 많은 사람들은 자신의 패스키를 즉시 사용할 수 없는 이 상황에서 무엇을 해야 할지 모릅니다. 이러한 상황에서 도움이 되는 패스키 기능 중 하나는 QR 코드와 블루투스 기술을 통해 여러 기기에서 패스키를 사용할 수 있는 기능입니다. 이 프로세스는 WebAuthn 사양에서 공식적으로 **하이브리드 전송(hybrid transport)**이라고 알려져 있습니다(이전 버전의 사양에서는 **클라우드 지원 블루투스 저전력(caBLE)**이라고 불렸습니다).
프로세스는 간단합니다. 패스키가 저장되어 있고 사진을 찍을 수 있는 기기, 즉 대부분의 경우 스마트폰이나 태블릿이 필요합니다. 이 기기는 해당 인증 인스턴스에 대해서만 새 기기로 터널을 열 수 있습니다. 이는 패스키의 무결성을 유지할 뿐만 아니라, 어디에 있든 누구의 기기를 사용하여 로그인하든 새 기기에서 계정에 대한 접근 권한을 부여할 수 있도록 보장합니다.
그러나 이 패스키 크로스 플랫폼 인증 기능은 그 유용성과 기술적 구현 모두에서 오해와 혼란으로 둘러싸여 있습니다. 이는 최근 제가 지역 IT 보안 밋업에 참석했을 때 다시 한번 느낀 점입니다. 이 글을 통해 우리는 복잡성을 풀고 이 크로스 플랫폼 패스키 인증(하이브리드 전송) 흐름을 구현하기 위한 권장 사항을 제공하여, 사용자에게 최상의 로그인 경험을 제공할 수 있도록 돕고자 합니다.
패스키는 기존 비밀번호를 더 안전하고 편리한 암호화 공개-개인 키 쌍으로 대체하는 사용자 인증의 한 형태입니다. 이 키 쌍은 각 사용자에게 고유하며 복잡한 비밀번호를 기억하는 번거로움 없이 신원을 확인하는 데 사용됩니다.
패스키의 장점은 이전의 비밀번호와 비교할 때 매우 많습니다. 가짜 웹사이트와 공유하도록 속일 수 없기 때문에 피싱의 위험을 크게 줄입니다. 또한, 비밀번호를 해독하는 데 사용되는 일반적인 방법인 무차별 대입 공격 및 사전 공격에 면역입니다. 패스키는 또한 긴 비밀번호 목록을 기억하거나 관리할 필요가 없애 사용자 친화적입니다.
패스키는 Google 비밀번호 관리자나 Apple iCloud 키체인(Microsoft는 Windows Hello로 곧 뒤따를 예정)과 같은 클라우드 계정이나, 1Password나 Dashlane과 같은 최신 패스키 지원 비밀번호 관리자에 저장되어 동기화됩니다. 그러나 기본적으로 패스키는 해당 생태계 및 클라우드 계정 동기화에 종속된다는 점을 아는 것이 중요합니다. 운영 체제는 개인 키를 내보낼 수 있는 인터페이스를 제공하지 않으며, 대부분의 기기에는 개인 키에 대한 접근을 방지하기 위한 추가적인 보안 조치를 제공하는 하드웨어 구성 요소가 있습니다. 예를 들어 iOS 기기의 Secure Enclave나 Windows 기기의 신뢰할 수 있는 플랫폼 모듈(TPM)이 있습니다. 운영 체제 제공자만이 암호화된 방식으로 패스키를 다른 기기에 동기화할 수 있습니다(궁극적으로 사용자의 생체 인식, 암호 또는 PIN으로 보호됨). 개인 키는 암호/PIN을 사용해야만 복원 및 해독할 수 있으며, 클라우드 계정에 대한 로그인 시도가 너무 많으면 파기됩니다(예: Apple은 클라우드 백엔드의 권한 있는 위치에서도 무차별 대입 공격을 방지하기 위해 속도 제한을 도입했으며, Google도 마찬가지입니다).
이러한 고유한 설계는 설명된 대로 패스키가 동기화되지 않으면 새 기기에서 패스키에 접근하는 것이 어려울 수 있음을 의미합니다. 이것이 바로 QR 코드와 블루투스 근접 확인을 통한 패스키 크로스 플랫폼 인증(하이브리드 전송) 방법이 존재하는 이유입니다. 이는 클라우드 계정/비밀번호 관리자를 통해 동기화할 필요 없이 기기 간에 패스키를 위한 안전한 다리를 제공하여, 패스키가 오직 사용자와 함께 남을 수 있다는 원칙을 유지합니다.
하이브리드 전송을 사용한 크로스 플랫폼 패스키 인증은 계정이 순수하게 패스키를 통해 접근될 때 기기 간 문제를 극복하는 데 도움이 됩니다. 모든 패스키가 클라우드 계정이나 비밀번호 관리자에 동기화되는 것은 아니므로, 기기 간에 패스키에 접근할 수 있는 신뢰할 수 있는 방법의 필요성은 특히 새 기기로 전환하거나 공유 기기에서 접근해야 할 때 중요해집니다.
패스키 크로스 플랫폼 인증(하이브리드 전송)을 용이하게 하려면 다음과 같은 하드웨어 요구 사항이 있습니다:
Ben Gould
Head of Engineering
I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.
10,000명 이상의 개발자가 Corbado를 신뢰하며 패스키로 인터넷을 더 안전하게 만들고 있습니다. 질문이 있으신가요? 저희는 패스키에 대한 150개 이상의 블로그 게시물을 작성했습니다.
패스키 커뮤니티 참여하기소프트웨어 관점에서는 다음과 같은 요구 사항이 있습니다:
출처: passkeys.dev
QR 코드를 통해 패스키 크로스 플랫폼 인증(하이브리드 전송)을 사용하는 프로세스는 다음과 같습니다:
패스키 크로스 플랫폼 인증(하이브리드 전송)용 QR 코드는 사용자가 등록된 패스키가 없는 기기에서 서비스에 접근하려고 시도하지만, 서비스는 사용자가 패스키를 가지고 있어야 한다는 것을 알고 있을 때 생성됩니다. 일반적으로 인증 인터페이스 내에 'QR 코드 스캔' 버튼이나 유사한 행동 유도 문구가 제공됩니다.
사용자 요청 시, 기기는 QR 코드 생성을 시작합니다. 이 QR 코드는 고유하고 시간 제한이 있는 세션 식별자를 인코딩합니다. 이 식별자는 인증 서버가 인증 프로세스 완료를 기다리는 동안 일시적으로 유지하는 세션에 연결됩니다.
사용자는 패스키를 사용할 수 있는 기기로 이 QR 코드를 스캔합니다. 보안 조치는 다음과 같습니다:
스캔된 QR 코드는 FIDO 스킴을 가진 특정 URI를 보유합니다. 예: FIDO:/07824133892604070278923969472008301099476228966286113051476699183587 6383562063181103169246410435938367110394959927031730060360967994421 343201235185697538107096654083332
QR 코드를 스캔하면 사용자의 두 번째 기기(예: 스마트폰 또는 태블릿)가 FIDO URI를 해석하고 인증 서버와 통신하여 사용자가 새 기기(예: 친구의 노트북)를 통해 인증을 시도하고 있다는 신호를 보냅니다. 이 작업은 서버가 이 인증 시도에 고유한 암호화 챌린지를 생성하도록 유도합니다.
챌린지는 패스키가 저장된 사용자의 두 번째 기기(예: 스마트폰 또는 태블릿)로 다시 전송됩니다. 그런 다음 기기는 개인 키가 기기를 떠나지 않고(예: 스마트폰 또는 태블릿) 패스키와 관련된 개인 키를 사용하여 디지털 서명을 생성합니다. 서명된 챌린지(서명)는 인터넷을 통해 안전하고 암호화된 터널을 통해 서버로 다시 전송되어 인증 시도의 무결성과 출처를 확인합니다.
서버는 이미 사용자 계정과 연결된 해당 공개 키를 사용하여 서명을 검증합니다. 성공적으로 검증되면 서버는 인증을 확인하고 사용자가 새 기기에서 서비스에 접근할 수 있도록 허용합니다.
고려해야 할 몇 가지 더 중요한 개인 정보 보호 및 보안 측면:
이러한 기술 및 보안 프로토콜을 준수함으로써 QR 코드 방식의 패스키 크로스 플랫폼 인증(하이브리드 전송)은 사용자가 새 기기에서 자신의 신원을 편리하게 인증할 수 있는 방법을 제공하면서 높은 수준의 보안을 유지합니다.
QR 코드 스캔 프로세스 외에도 블루투스(caBLE)를 통한 근접 확인도 있습니다. 클라이언트와 인증자가 물리적으로 서로 가깝다는 것을 확인하는 것은 WebAuthn 프로토콜의 주요 이점 중 하나입니다. 이 프로세스의 내부 작동에 대한 자세한 내용은 다음과 같습니다:
**블루투스 저전력(BLE)**은 단거리 데이터 교환을 위해 설계된 무선 통신 기술입니다. 인증 과정에서 기기의 물리적 근접성을 확인하는 데 중추적인 역할을 합니다.
caBLE은 BLE를 사용하여 기기 간에 인증 정보를 안전하게 전송하는 것을 용이하게 하는 프로토콜입니다. 패스키 크로스 플랫폼 인증(하이브리드 전송)에 caBLE를 사용할 때, 패스키를 보유한 기기는 BLE 신호를 통해 요청하는 기기의 근접성을 확인합니다. 근접성이 확인되면 인증 프로세스가 진행되며, 안전한 로컬 통신을 위해 BLE를 활용합니다.
이 방법은 일반적으로 사용자의 직접적인 상호 작용이 덜 필요하기 때문에 사용자 경험이 향상됩니다. 물리적으로 가까운 거리에 있는 기기들이 서로를 자동으로 감지합니다. 보안 측면에서 caBLE은 상당한 이점을 제공합니다. 두 기기가 서로 가까이 있을 때만 인증 프로세스가 수행되도록 보장하여 원격 공격자가 인증 프로세스를 시작하는 것을 방지합니다.
악성 사이트로 리디렉션되는 QR 코드를 받았다고 상상해 보십시오. 이 QR 코드를 통해 인증이 수행되면 세션이나 쿠키가 탈취될 위험이 있습니다. BLE는 시각적 스캔에 의존하지 않고 기기의 물리적 존재에 의존함으로써 이 문제를 우회합니다. 이 근접 확인은 인터넷이나 시각적 매체를 통해 발생하지 않으므로 중간자 공격의 위험을 최소화합니다.
다른 방법과 달리 caBLE는 실제로 패스키와 같은 인증 데이터를 교환하지 않습니다. 대신, 기기가 물리적으로 가깝다는 것을 확인하기 위한 확인 채널로 BLE를 사용합니다. 이 확인은 BLE 근접성이 요소 중 하나인 다단계 인증 프로세스의 일부로 설계되어, 다른 요소가 손상되더라도 물리적 근접성 없이는 접근이 허용되지 않도록 보장합니다.
caBLE 프로토콜을 통합함으로써 개발자는 인증 프로세스의 전반적인 보안을 강화하는 안전하고 사용자 친화적인 패스키 크로스 플랫폼 인증(하이브리드 전송) 방법을 제공할 수 있습니다. 근접 확인은 사용자에게는 간단하면서도 특정 유형의 정교한 사이버 공격에 대해 효과적으로 보호하는 추가적인 보호 계층을 추가합니다.
이 패스키 크로스 플랫폼 인증(하이브리드 전송) 방법의 장점은 다음과 같습니다:
QR 코드와 블루투스(하이브리드 전송)를 통한 크로스 플랫폼 패스키 인증은 아무런 가능성을 제공하지 않는 것에 비해 크로스 플랫폼 시나리오에서 UX를 개선하는 방법입니다. 그러나 사용자 흐름은 대부분의 사용자에게 완전히 새롭기 때문에, 기술에 익숙하지 않은 많은 사용자가 이 흐름을 처음 접했을 때 무슨 일이 일어나고 있는지 이해할 것으로 기대하지 않습니다. QR 코드 흐름을 도입하는 것과 유사한 유일한 경우는 WhatsApp Web이나 Discord와 같은 로그인 흐름에서 QR 코드가 사용되는 경우입니다(여기서는 기능이 다르지만). 따라서 분석된 QR 코드/블루투스(하이브리드 전송)를 통한 크로스 플랫폼 패스키 인증 프로세스는 크로스 플랫폼 시나리오에서 수동으로 자격 증명을 입력할 필요가 없으므로 사용자 노력을 최소화하지만, 여전히 전체 흐름은 대부분의 사용자에게 알려져 있지 않습니다.
패스키 크로스 플랫폼 인증(하이브리드 전송)의 보안은 고급 암호화 기술로 강화됩니다. 인증을 위해 QR 코드를 스캔하거나 블루투스 연결이 이루어지면, 암호화 챌린지와 응답은 의도된 기기만이 인증 프로세스를 성공적으로 완료할 수 있도록 보장합니다.
블루투스를 통한 근접 확인은 추가적인 보안 계층을 추가하여, 인증 시도가 보조 기기에 물리적으로 접근할 수 있는 사람에 의해 이루어지고 있음을 확인합니다.
크로스 플랫폼 인증(하이브리드 전송) 과정에서 패스키는 중간 장치나 서버에 일시적으로 저장되지 않으므로, 전송 과정에서 패스키가 가로채지거나 유출될 위험을 방지합니다. 인증은 실시간으로 이루어지며, 패스키는 사용자의 기본 장치에 바인딩된 상태를 유지하여 무결성을 보존합니다.
QR 코드 및 블루투스 인증 방법은 본질적으로 피싱에 대한 보호를 제공합니다. 인증 프로세스에는 사용자의 신뢰할 수 있는 장치에 특정한 물리적 조치가 필요하기 때문에 사용자가 악성 사이트에 패스키를 제공하도록 속을 가능성이 적습니다.
QR 코드를 스캔하거나 블루투스를 통해 연결하는 과정은 일반적으로 신뢰할 수 있는 환경에서 발생하므로 사용자가 실수로 자격 증명을 손상시킬 가능성을 줄입니다.
이 패스키 크로스 플랫폼 인증(하이브리드 전송) 방법의 단점은 다음과 같습니다:
새로운 기술을 도입하면 특히 기술에 익숙하지 않은 사용자에게 혼란을 줄 수 있습니다. QR 코드와 블루투스(하이브리드 전송)를 통한 패스키 크로스 플랫폼 인증은 기존 인증 방법에서 크게 벗어난 것이므로 일부 사용자는 새로운 프로세스를 이해하기 어려워할 수 있으며, 이는 채택률을 늦출 수 있습니다. 그러나 우리는 사용자가 결국 익숙해질 것으로 예상하므로, 처음에는 변화가 더 어려울 수 있지만 시간이 지남에 따라 더 부드럽고 수용될 것입니다.
패스키 크로스 플랫폼 인증(하이브리드 전송)의 성공은 사용자의 기기가 QR 코드를 스캔할 수 있는 카메라와 블루투스 기능과 같은 필요한 기능을 갖추고 있는지에 크게 의존합니다. 이러한 기능이 없는 구형 기기를 사용하는 사용자는 패스키 크로스 플랫폼 인증(하이브리드 전송)을 이용할 수 없으므로 하드웨어 제한에 따른 디지털 격차가 발생합니다.
사용자 행동은 예측할 수 없으며, QR 코드 스캔이나 블루투스 활성화와 같은 특정 작업을 수행하도록 사용자에 의존하면 사용자 오류가 발생할 수 있습니다. 예를 들어, 블루투스는 페어링 문제, 검색 문제 및 보안 거래에 대한 무선 기술에 대한 일반적인 사용자 불신으로 인해 때때로 UX 문제로 간주될 수 있습니다.
개발자는 최신 인증 방법을 지원하기 위해 시스템을 지속적으로 업데이트하고 유지 관리해야 하는 과제에 직면합니다. 기존 시스템에 패스키 크로스 플랫폼 인증(하이브리드 전송)을 통합하려면 개발자가 새로운 표준을 파악하고, 새로운 API를 채택하고, 이전 버전과의 호환성을 보장해야 하므로 리소스 집약적이고 시간이 많이 소요될 수 있습니다.
iCloud 키체인과 같은 동기화된 클라우드 계정이나 비밀번호 관리자를 사용하지 않는 경우, 모든 새 기기 또는 후속 로그인 요청에 대해 새 패스키를 생성해야 합니다. 이는 사용자 경험에 복잡성을 더할 수 있으며, 사용자가 프로세스에 익숙하지 않거나 직관적으로 만들어지지 않은 경우 좌절감을 유발할 수 있습니다.
패스키 크로스 플랫폼 인증(하이브리드 전송)과 같은 새로운 보안 방법을 구현할 때는 사용자 교육이 본질적으로 필요합니다. 사용자가 QR 코드와 블루투스를 안전하게 사용하는 방법을 이해하도록 하려면 명확한 의사소통과 광범위한 고객 지원이 필요할 수 있습니다.
QR 코드와 블루투스(하이브리드 전송)를 통한 패스키 크로스 플랫폼 인증은 인증 기술의 상당한 발전을 보여주지만, 이러한 잠재적인 단점은 사용자 친화적인 디자인, 강력한 지원 시스템, 그리고 기존 방법에서 혁신적인 방법으로의 점진적이고 잘 전달된 전환의 필요성을 강조합니다. 모든 기술적 변화와 마찬가지로, 혁신의 이점과 과제의 균형을 맞추는 것이 성공적인 구현과 광범위한 사용자 수용의 핵심이 될 것입니다.
면책 조항: 다음 테스트에서는 하드웨어 보안 키(예: YubiKey)를 무시하고 기기에 내장된 플랫폼 인증자(예: Face ID, Touch ID, Windows Hello)만 사용합니다. 하드웨어 보안 키(예: YubiKey)의 경우, 전송(transports) 값은 예를 들어 usb 또는 nfc가 됩니다.
다음 기기/브라우저 조합과 Passkeys Debugger를 사용하여 동작을 테스트합니다. Android는 크로스 플랫폼 인증(하이브리드 전송) 클라이언트로 작동할 수 없으므로 고려하지 않습니다(위의 3.2 소프트웨어 요구 사항 표 참조):
동작을 테스트하기 위해 각 조합에 대해 다음 속성을 가진 새 패스키를 생성합니다:
패스키를 성공적으로 생성한 후, allowCredentials
WebAuthn 서버 속성의 입력을 수정하고
로그인 요청을 시작합니다. 패스키를 생성한 기기에서 패스키가 삭제된 상황을 모방하여,
기기/브라우저가 QR 코드/블루투스를 통해 패스키를 제공할 수 있는 다른 기기를 찾도록 합니다.
따라서 credential ID
를 변경하고 값으로 CHANGED-ID를 할당하여 일치가 실패하도록 합니다.
또한, allowCredentials
에 있는 WebAuthn 자격 증명의 transports
속성을 변경하고 각
기기/브라우저 조합에 대해 다음 값을 할당합니다:
WebAuthn 테스트 사이트에는 사용자 에이전트 힌트를 위한 새로운 WebAuthn Level 3 기능도 제공됩니다. 이 기능은 신뢰 당사자(relying party)가 로그인 요청을 가장 사용자 친화적인 방식으로 완료할 수 있는 방법에 대한 특정 가정을 가지고 있을 때 사용자 경험을 향상시킬 수 있습니다. 이 테스트에서는 아직 출시되지 않았으므로 이 기능을 무시했습니다. 자세한 내용은 사양을 참조하십시오.
예상대로 로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하여 다른 기기에서 패스키를 사용하도록 제안합니다(시스템이 이 사용자에 대한 패스키가 존재함을 알고 있기 때문).
상당히 혼란스럽게도, 내부 자격 증명만 허용했음에도 불구하고 여기에서도 QR 코드가 표시됩니다. 이 동작에 대한 타당한 이유를 찾을 수 없었습니다.
로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.
어떤 이유에서인지, 모달의 일부가 설치된 언어 중 하나인 독일어로 나타납니다.
예상대로 모든 형태의 패스키 인증이 허용됩니다: Windows Hello, QR 코드, 알려진 기기 및 하드웨어 보안 키를 통해.
예상대로 로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하여 다른 기기에서 패스키를 사용하도록 제안합니다(시스템이 이 사용자에 대한 패스키가 존재함을 알고 있기 때문).
상당히 혼란스럽게도, 내부 자격 증명만 허용했음에도 불구하고 여기에서도 QR 코드가 표시됩니다. 이 동작에 대한 타당한 이유를 찾을 수 없었습니다.
로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.
어떤 이유에서인지, 모달의 일부가 설치된 언어 중 하나인 독일어로 나타납니다.
예상대로 모든 형태의 패스키 인증이 허용됩니다: Windows Hello, QR 코드, 알려진 기기 및 하드웨어 보안 키를 통해.
패스키를 생성할 때 다음 오류가 발생했습니다(그래도 패스키는 생성됨):
error: TypeError: 'toJSON' called on an object that does not implement interface PublicKeyCredential.
예상대로 로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하여 다른 기기에서 패스키를 사용하도록 제안합니다(시스템이 이 사용자에 대한 패스키가 존재함을 알고 있기 때문).
상당히 혼란스럽게도, 내부 자격 증명만 허용했음에도 불구하고 여기에서도 QR 코드가 표시됩니다. 이 동작에 대한 타당한 이유를 찾을 수 없었습니다.
로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.
어떤 이유에서인지, 모달의 일부가 설치된 언어 중 하나인 독일어로 나타납니다.
예상대로 모든 형태의 패스키 인증이 허용됩니다: Windows Hello, QR 코드, 알려진 기기 및 하드웨어 보안 키를 통해.
예상대로 로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하여 다른 기기에서 패스키를 사용하도록 제안합니다(시스템이 이 사용자에 대한 패스키가 존재함을 알고 있기 때문). 또한, 알려진 기기 중 하나를 직접 선택하여 거기서 패스키를 사용할 수도 있습니다.
모달은 Windows의 Chrome 119에서의 것과 상당히 다릅니다.
이는 예상된 동작입니다. 내부 패스키만 사용하도록 허용했지만 기기에서 내부 자격 증명을 찾을 수 없기 때문입니다(하이브리드 패스키 사용은 허용되지 않음). 이 단계에서 패스키 인증이 실패하며, 실제 구현에서는 대체 인증 방법을 제공해야 합니다.
로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다. 또한, 알려진 기기 중 하나를 직접 선택하여 거기서 패스키를 사용할 수도 있습니다.
모달은 Windows의 Chrome 119에서의 것과 상당히 다릅니다.
예상대로 모든 형태의 패스키 인증이 허용됩니다: Touch ID, QR 코드, 알려진 기기 및 하드웨어 보안 키를 통해.
예상대로 로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하여 다른 기기에서 패스키를 사용하도록 제안합니다(시스템이 이 사용자에 대한 패스키가 존재함을 알고 있기 때문).
상당히 혼란스럽게도, 내부 자격 증명만 허용했음에도 불구하고 여기에서도 QR 코드가 표시됩니다. 이 동작에 대한 타당한 이유를 찾을 수 없었습니다.
로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.
예상대로 대부분의 패스키 인증 형태가 허용됩니다: Touch ID, QR 코드 및 하드웨어 보안 키를 통해. 어떤 이유에서인지 알려진 기기는 표시되지 않습니다.
예상대로 로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하여 다른 기기에서 패스키를 사용하도록 제안합니다(시스템이 이 사용자에 대한 패스키가 존재함을 알고 있기 때문).
상당히 혼란스럽게도, 내부 자격 증명만 허용했음에도 불구하고 여기에서도 QR 코드가 표시됩니다. 이 동작에 대한 타당한 이유를 찾을 수 없었습니다.
로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.
예상대로 대부분의 패스키 인증 형태가 허용됩니다: Face ID, QR 코드 및 하드웨어 보안 키를 통해. 어떤 이유에서인지 알려진 기기는 표시되지 않습니다.
예상대로 로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하여 다른 기기에서 패스키를 사용하도록 제안합니다(시스템이 이 사용자에 대한 패스키가 존재함을 알고 있기 때문).
상당히 혼란스럽게도, 내부 자격 증명만 허용했음에도 불구하고 여기에서도 QR 코드가 표시됩니다. 이 동작에 대한 타당한 이유를 찾을 수 없었습니다.
로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.
예상대로 대부분의 패스키 인증 형태가 허용됩니다: Face ID, QR 코드 및 하드웨어 보안 키를 통해. 어떤 이유에서인지 알려진 기기는 표시되지 않습니다.
다음으로, Windows 10 기기의 경우 한 단계 더 나아가 블루투스가 비활성화되었거나 Windows 10 컴퓨터에서 일반적으로 사용할 수 없는 경우의 동작을 분석하기로 결정했습니다. 특히 구형 데스크톱 기기의 경우, 블루투스 모듈이 없는 경우가 많아 QR 코드와 블루투스를 통한 크로스 플랫폼 인증이 불가능한 매우 일반적인 시나리오입니다.
8.8.1.1 transports: [internal, hybrid]
예상대로 로컬 패스키가 일치하지 않으므로, 다른 기기에서 패스키를 사용하도록 제안하거나(시스템이 이 사용자에 대한 패스키가 존재함을 알고 있기 때문에 - 첫 번째 스크린샷) QR 코드를 스캔하도록 선택할 수 있습니다(두 번째 스크린샷).
8.8.1.2 transports: [internal]
상당히 혼란스럽게도, credential ID
를 변경했음에도 불구하고 Windows Hello PIN 코드(또는
기기에 설정된 경우 지문/얼굴 스캔)를 입력하라는 메시지가 표시됩니다(allowCredentials
속성에 지정되지 않았으므로 실제로는 자격 증명을 찾지 못해야 함). 그러나 Windows Hello PIN
코드를 제출하면 "NotAllowedError: The operation either timed out or was not allowed. See:
https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-
client." 오류가 발생합니다. 사용자 관점에서는 다소 혼란스러운 동작이지만, 사용자 동의 없이
사용자의 패스키에 대한 정보를 제공할 수 있으므로 타당합니다.
8.8.1.3 transports 속성 설정 안 함
로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.
8.8.1.4 빈 allowCredentials
예상대로 모든 형태의 패스키 인증이 허용됩니다: Windows Hello, QR 코드, 알려진 기기 및 하드웨어 보안 키를 통해.
8.8.2.1 transports: [internal, hybrid]
사용자에게 무엇을 해야 하고 어떻게 인증할 수 있는지 명시적으로 설명하지 않기 때문에 매우 혼란스러운 메시지입니다. 유일한 옵션은 "취소"를 클릭하는 것이므로 이 시나리오는 막다른 길이 됩니다.
8.8.2.2 transports: [internal]
이 동작은 블루투스가 활성화된 경우와 동일합니다. credential ID
를 변경했음에도 불구하고
사용자가 Windows Hello PIN 코드(또는 기기에 설정된 경우 지문/얼굴 스캔)를 입력하라는
메시지가 표시되는 것은 매우 혼란스럽습니다(allowCredentials
속성에 지정되지 않았으므로
실제로는 자격 증명을 찾지 못해야 함). 그러나 Windows Hello PIN 코드를 제출하면
"NotAllowedError: The operation either timed out or was not allowed. See:
https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-
client." 오류가 발생합니다. 사용자 관점에서는 다소 혼란스러운 동작이지만, 사용자 동의 없이
사용자의 패스키에 대한 정보를 제공할 수 있으므로 타당합니다.
8.8.2.3 transports 속성 설정 안 함
로컬 패스키가 일치하지 않으므로, 유일한 옵션은 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하는 것입니다.
8.8.2.4 빈 allowCredentials
패스키 인증은 Windows Hello와 하드웨어 보안 키를 통해서만 가능합니다.
8.9.1.1 transports: [internal, hybrid]
예상대로 로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하여 다른 기기에서 패스키를 사용하도록 제안합니다(시스템이 이 사용자에 대한 패스키가 존재함을 알고 있기 때문).
8.9.1.2 transports: [internal]
상당히 혼란스럽게도, 자격 증명 ID를 변경했음에도 불구하고 Windows Hello PIN 코드(또는 기기에 설정된 경우 지문/얼굴 스캔)를 입력하라는 메시지가 표시됩니다(allowCredentials 속성에 지정되지 않았으므로 실제로는 자격 증명을 찾지 못해야 함). 그러나 Windows Hello PIN 코드를 제출하면 "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." 오류가 발생합니다. 사용자 관점에서는 다소 혼란스러운 동작이지만, 사용자 동의 없이 사용자의 패스키에 대한 정보를 제공할 수 있으므로 타당합니다.
8.9.1.3 transports 속성 설정 안 함
로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.
8.9.1.4 빈 allowCredentials
예상대로 모든 형태의 패스키 인증이 허용됩니다: Windows Hello, QR 코드 및 하드웨어 보안 키를 통해. 어떤 이유에서인지 알려진 기기는 표시되지 않습니다.
8.9.2.1 transports: [internal, hybrid]
사용자에게 무엇을 해야 하고 어떻게 인증할 수 있는지 명시적으로 설명하지 않기 때문에 매우 혼란스러운 메시지입니다. 유일한 옵션은 "취소"를 클릭하는 것이므로 이 시나리오는 막다른 길이 됩니다.
8.9.2.2 transports: [internal]
이 동작은 블루투스가 활성화된 경우와 동일합니다. 자격 증명 ID를 변경했음에도 불구하고 사용자가 Windows Hello PIN 코드(또는 기기에 설정된 경우 지문/얼굴 스캔)를 입력하라는 메시지가 표시되는 것은 매우 혼란스럽습니다(allowCredentials 속성에 지정되지 않았으므로 실제로는 자격 증명을 찾지 못해야 함). 그러나 Windows Hello PIN 코드를 제출하면 "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." 오류가 발생합니다. 사용자 관점에서는 다소 혼란스러운 동작이지만, 사용자 동의 없이 사용자의 패스키에 대한 정보를 제공할 수 있으므로 타당합니다.
8.9.2.3 transports 속성 설정 안 함
로컬 패스키가 일치하지 않으므로, 유일한 옵션은 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하는 것입니다.
8.9.2.4 빈 allowCredentials
패스키 인증은 Windows Hello와 하드웨어 보안 키를 통해서만 가능합니다.
8.10.1.1 transports: [internal, hybrid]
예상대로 로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하여 다른 기기에서 패스키를 사용하도록 제안합니다(시스템이 이 사용자에 대한 패스키가 존재함을 알고 있기 때문).
8.10.1.2 transports: [internal]
상당히 혼란스럽게도, 자격 증명 ID를 변경했음에도 불구하고 Windows Hello PIN 코드(또는 기기에 설정된 경우 지문/얼굴 스캔)를 입력하라는 메시지가 표시됩니다(allowCredentials 속성에 지정되지 않았으므로 실제로는 자격 증명을 찾지 못해야 함). 그러나 Windows Hello PIN 코드를 제출하면 "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." 오류가 발생합니다. 사용자 관점에서는 다소 혼란스러운 동작이지만, 사용자 동의 없이 사용자의 패스키에 대한 정보를 제공할 수 있으므로 타당합니다.
8.10.1.3 transports 속성 설정 안 함
로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.
8.10.1.4 빈 allowCredentials
예상대로 모든 형태의 패스키 인증이 허용됩니다: Windows Hello, QR 코드 및 하드웨어 보안 키를 통해. 어떤 이유에서인지 알려진 기기는 표시되지 않습니다.
8.10.2.1 transports: [internal, hybrid]
사용자에게 무엇을 해야 하고 어떻게 인증할 수 있는지 명시적으로 설명하지 않기 때문에 매우 혼란스러운 메시지입니다. 유일한 옵션은 "취소"를 클릭하는 것이므로 이 시나리오는 막다른 길이 됩니다. 어떤 이유에서인지 Windows 보안 모달의 일부가 이 기기에 설치된 두 번째 언어인 독일어로 표시됩니다.
8.10.2.2 transports: [internal]
이 동작은 블루투스가 활성화된 경우와 동일합니다. 자격 증명 ID를 변경했음에도 불구하고 사용자가 Windows Hello PIN 코드(또는 기기에 설정된 경우 지문/얼굴 스캔)를 입력하라는 메시지가 표시되는 것은 매우 혼란스럽습니다(allowCredentials 속성에 지정되지 않았으므로 실제로는 자격 증명을 찾지 못해야 함). 그러나 Windows Hello PIN 코드를 제출하면 "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." 오류가 발생합니다. 사용자 관점에서는 다소 혼란스러운 동작이지만, 사용자 동의 없이 사용자의 패스키에 대한 정보를 제공할 수 있으므로 타당합니다.
8.10.2.3 transports 속성 설정 안 함
로컬 패스키가 일치하지 않으므로, 유일한 옵션은 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하는 것입니다.
8.10.2.4 빈 allowCredentials
패스키 인증은 Windows Hello와 하드웨어 보안 키를 통해서만 가능합니다.
8.11.1.1 transports: [internal, hybrid]
예상대로 로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하여 다른 기기에서 패스키를 사용하도록 제안합니다(시스템이 이 사용자에 대한 패스키가 존재함을 알고 있기 때문).
8.11.1.2 transports: [internal]
상당히 혼란스럽게도, 자격 증명 ID를 변경했음에도 불구하고 Windows Hello PIN 코드(또는 기기에 설정된 경우 지문/얼굴 스캔)를 입력하라는 메시지가 표시됩니다(allowCredentials 속성에 지정되지 않았으므로 실제로는 자격 증명을 찾지 못해야 함). 그러나 Windows Hello PIN 코드를 제출하면 "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." 오류가 발생합니다. 사용자 관점에서는 다소 혼란스러운 동작이지만, 사용자 동의 없이 사용자의 패스키에 대한 정보를 제공할 수 있으므로 타당합니다.
8.11.1.3 transports 속성 설정 안 함
로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.
8.11.1.4 빈 allowCredentials
예상대로 모든 형태의 패스키 인증이 허용됩니다: Windows Hello, QR 코드 및 하드웨어 보안 키를 통해. 어떤 이유에서인지 알려진 기기는 표시되지 않습니다.
8.11.2.1 transports: [internal, hybrid]
사용자에게 무엇을 해야 하고 어떻게 인증할 수 있는지 명시적으로 설명하지 않기 때문에 매우 혼란스러운 메시지입니다. 유일한 옵션은 "취소"를 클릭하는 것이므로 이 시나리오는 막다른 길이 됩니다.
8.11.2.2 transports: [internal]
이 동작은 블루투스가 활성화된 경우와 동일합니다. 자격 증명 ID를 변경했음에도 불구하고 사용자가 Windows Hello PIN 코드(또는 기기에 설정된 경우 지문/얼굴 스캔)를 입력하라는 메시지가 표시되는 것은 매우 혼란스럽습니다(allowCredentials 속성에 지정되지 않았으므로 실제로는 자격 증명을 찾지 못해야 함). 그러나 Windows Hello PIN 코드를 제출하면 "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." 오류가 발생합니다. 사용자 관점에서는 다소 혼란스러운 동작이지만, 사용자 동의 없이 사용자의 패스키에 대한 정보를 제공할 수 있으므로 타당합니다.
8.11.2.3 transports 속성 설정 안 함
로컬 패스키가 일치하지 않으므로, 유일한 옵션은 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하는 것입니다.
8.11.2.4 빈 allowCredentials
패스키 인증은 Windows Hello와 하드웨어 보안 키를 통해서만 가능합니다.
excludeCredentials
및 allowCredentials
속성에서 정의해야 합니다. WebAuthn 서버의
excludeCredentials
속성에서는 이미 생성된 자격 증명에 대한 전송 정보를 볼 수 있습니다.
allowCredentials
속성에서는 로그인 프로세스의 동작을 지정할 수 있습니다(위의 8. 실제
테스트: 하이브리드 전송 패스키 동작 참조).QR 코드/블루투스(하이브리드 전송)를 통한 패스키 크로스 플랫폼 인증은 보안과 UX 사이의 균형을 제공합니다. 그러나 대부분의 사용자에게는 완전히 새로운 프로세스이며 많은 혼란스러운 상황을 유발할 수 있으므로 이를 홍보할지 신중하게 생각해야 합니다.
이 글을 통해 QR 코드/블루투스를 통한 패스키 크로스 플랫폼 인증(하이브리드 전송) 주제에 대해 약간의 빛을 비추고, 설정 방법과 다양한 기기/브라우저 조합에서의 동작을 설명할 수 있었기를 바랍니다. 질문이 있으시면 패스키 커뮤니티를 통해 문의하시거나 패스키 Substack을 구독해 주세요. 패스키를 널리 알려 인터넷을 더 안전한 곳으로 만듭시다.
Enjoyed this read?
🤝 Join our Passkeys Community
Share passkeys implementation tips and get support to free the world from passwords.
🚀 Subscribe to Substack
Get the latest news, strategies, and insights about passkeys sent straight to your inbox.
Related Articles
Table of Contents