WebAuthn 패스키 QR 코드와 블루투스: 하이브리드 전송

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.

1. 소개#

패스키는 사용자 인증의 사실상 표준으로 점차 비밀번호를 대체하고 있습니다. 기존 비밀번호와 달리 패스키는 특정 생태계(예: iCloud 키체인, Google 비밀번호 관리자, Windows Hello 또는 1Password나 Dashlane과 같은 비밀번호 관리자)에 종속됩니다. 패스키는 암기하도록 설계된 것이 아니라, 기기와 원활하게 통합되어 기본적으로 훌륭한 사용자 경험을 제공하도록 만들어졌습니다.

개인 컴퓨터가 아닌 공용 터미널이나 친구의 노트북에서 패스키로 보호된 계정에 로그인해야 하는 상황을 상상해 보세요. 이 시나리오는 매우 흔하며 안전하면서도 편리한 인증 방법이 필요하지만, 많은 사람들은 자신의 패스키를 즉시 사용할 수 없는 이 상황에서 무엇을 해야 할지 모릅니다. 이러한 상황에서 도움이 되는 패스키 기능 중 하나는 QR 코드와 블루투스 기술을 통해 여러 기기에서 패스키를 사용할 수 있는 기능입니다. 이 프로세스는 WebAuthn 사양에서 공식적으로 **하이브리드 전송(hybrid transport)**이라고 알려져 있습니다(이전 버전의 사양에서는 **클라우드 지원 블루투스 저전력(caBLE)**이라고 불렸습니다).

Want to find out how many people use passkeys?

View Adoption Data

프로세스는 간단합니다. 패스키가 저장되어 있고 사진을 찍을 수 있는 기기, 즉 대부분의 경우 스마트폰이나 태블릿이 필요합니다. 이 기기는 해당 인증 인스턴스에 대해서만 새 기기로 터널을 열 수 있습니다. 이는 패스키의 무결성을 유지할 뿐만 아니라, 어디에 있든 누구의 기기를 사용하여 로그인하든 새 기기에서 계정에 대한 접근 권한을 부여할 수 있도록 보장합니다.

그러나 이 패스키 크로스 플랫폼 인증 기능은 그 유용성과 기술적 구현 모두에서 오해와 혼란으로 둘러싸여 있습니다. 이는 최근 제가 지역 IT 보안 밋업에 참석했을 때 다시 한번 느낀 점입니다. 이 글을 통해 우리는 복잡성을 풀고 이 크로스 플랫폼 패스키 인증(하이브리드 전송) 흐름을 구현하기 위한 권장 사항을 제공하여, 사용자에게 최상의 로그인 경험을 제공할 수 있도록 돕고자 합니다.

2. 패스키: 동기화되거나 단일 기기에서만 사용 가능#

패스키는 기존 비밀번호를 더 안전하고 편리한 암호화 공개-개인 키 쌍으로 대체하는 사용자 인증의 한 형태입니다. 이 키 쌍은 각 사용자에게 고유하며 복잡한 비밀번호를 기억하는 번거로움 없이 신원을 확인하는 데 사용됩니다.

패스키의 장점은 이전의 비밀번호와 비교할 때 매우 많습니다. 가짜 웹사이트와 공유하도록 속일 수 없기 때문에 피싱의 위험을 크게 줄입니다. 또한, 비밀번호를 해독하는 데 사용되는 일반적인 방법인 무차별 대입 공격 및 사전 공격에 면역입니다. 패스키는 또한 긴 비밀번호 목록을 기억하거나 관리할 필요가 없애 사용자 친화적입니다.

패스키는 Google 비밀번호 관리자나 Apple iCloud 키체인(Microsoft는 Windows Hello로 곧 뒤따를 예정)과 같은 클라우드 계정이나, 1Password나 Dashlane과 같은 최신 패스키 지원 비밀번호 관리자에 저장되어 동기화됩니다. 그러나 기본적으로 패스키는 해당 생태계 및 클라우드 계정 동기화에 종속된다는 점을 아는 것이 중요합니다. 운영 체제는 개인 키를 내보낼 수 있는 인터페이스를 제공하지 않으며, 대부분의 기기에는 개인 키에 대한 접근을 방지하기 위한 추가적인 보안 조치를 제공하는 하드웨어 구성 요소가 있습니다. 예를 들어 iOS 기기의 Secure Enclave나 Windows 기기의 신뢰할 수 있는 플랫폼 모듈(TPM)이 있습니다. 운영 체제 제공자만이 암호화된 방식으로 패스키를 다른 기기에 동기화할 수 있습니다(궁극적으로 사용자의 생체 인식, 암호 또는 PIN으로 보호됨). 개인 키는 암호/PIN을 사용해야만 복원 및 해독할 수 있으며, 클라우드 계정에 대한 로그인 시도가 너무 많으면 파기됩니다(예: Apple은 클라우드 백엔드의 권한 있는 위치에서도 무차별 대입 공격을 방지하기 위해 속도 제한을 도입했으며, Google도 마찬가지입니다).

이러한 고유한 설계는 설명된 대로 패스키가 동기화되지 않으면 새 기기에서 패스키에 접근하는 것이 어려울 수 있음을 의미합니다. 이것이 바로 QR 코드와 블루투스 근접 확인을 통한 패스키 크로스 플랫폼 인증(하이브리드 전송) 방법이 존재하는 이유입니다. 이는 클라우드 계정/비밀번호 관리자를 통해 동기화할 필요 없이 기기 간에 패스키를 위한 안전한 다리를 제공하여, 패스키가 오직 사용자와 함께 남을 수 있다는 원칙을 유지합니다.

Are your users passkey-ready?

Test Passkey-Readiness

3. 크로스 플랫폼 패스키 인증의 기술적 설정#

하이브리드 전송을 사용한 크로스 플랫폼 패스키 인증은 계정이 순수하게 패스키를 통해 접근될 때 기기 간 문제를 극복하는 데 도움이 됩니다. 모든 패스키가 클라우드 계정이나 비밀번호 관리자에 동기화되는 것은 아니므로, 기기 간에 패스키에 접근할 수 있는 신뢰할 수 있는 방법의 필요성은 특히 새 기기로 전환하거나 공유 기기에서 접근해야 할 때 중요해집니다.

3.1 하드웨어 요구 사항#

패스키 크로스 플랫폼 인증(하이브리드 전송)을 용이하게 하려면 다음과 같은 하드웨어 요구 사항이 있습니다:

WebAuthn 지원: 기기는 WebAuthn을 지원해야 합니다. 이는 최신 패스키 데이터 분석에 따르면 이미 99%의 기기에서 지원됩니다.
QR 코드 스캔용 카메라: 기기에는 QR 코드를 스캔할 수 있는 카메라가 필요합니다. 대부분의 최신 스마트폰에는 이 기능이 있는 카메라가 장착되어 있습니다. 또한, 카메라에는 내장된 QR 스캔 기능이 필요합니다(대부분의 기기가 기본적으로 가지고 있음). 카메라가 지원하지 않는 경우, 온라인 QR 스캐너도 좋은 옵션입니다. 그렇지 않으면 QR 코드 앱을 설치하는 것도 좋습니다.
블루투스 기능: 클라우드 지원 블루투스 저전력(caBLE)은 기기 간의 근접 기반 보안 연결을 설정하는 데 사용됩니다. 찾아야 할 버전은 블루투스 4.0 이상이며, 이는 WebAuthn용 caBLE 확장을 활성화합니다.
인터넷 연결: 실시간 데이터 전송이 필요한 확인 단계를 수행하기 위해 터널을 여는 교환이 포함되므로 두 기기 모두에 안정적인 인터넷 연결이 필요합니다.

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개 이상의 블로그 게시물을 작성했습니다.

패스키 커뮤니티 참여하기

3.2 소프트웨어 요구 사항#

소프트웨어 관점에서는 다음과 같은 요구 사항이 있습니다:

WebAuthn 서버 구성: 당연히 공개 키를 관리하는 WebAuthn 서버가 있어야 합니다. 여기에는 사용자의 계정을 여러 인증자에 연결하고 인증 절차를 시작하도록 서버를 설정하는 것이 포함됩니다.
Web Bluetooth API: 블루투스 근접 확인을 위해서는 브라우저에서 기기의 블루투스 기능을 트리거하는 Web Bluetooth API에 접근해야 합니다.
운영 체제 요구 사항: 2025년 3월 기준 여러 운영 체제의 크로스 디바이스 인증 지원에 대한 다음 표를 참조하십시오. 인증자(Authenticator)는 패스키를 보유한 기기(이 시나리오에서는 스마트폰)를 의미합니다. 클라이언트(Client)는 QR 코드를 생성하고 사용자가 로그인하려는 기기(이 시나리오에서는 데스크톱)를 의미합니다:

출처: passkeys.dev

4. 패스키: QR 코드#

QR 코드를 통해 패스키 크로스 플랫폼 인증(하이브리드 전송)을 사용하는 프로세스는 다음과 같습니다:

4.1 패스키 크로스 플랫폼 인증 시작#

패스키 크로스 플랫폼 인증(하이브리드 전송)용 QR 코드는 사용자가 등록된 패스키가 없는 기기에서 서비스에 접근하려고 시도하지만, 서비스는 사용자가 패스키를 가지고 있어야 한다는 것을 알고 있을 때 생성됩니다. 일반적으로 인증 인터페이스 내에 'QR 코드 스캔' 버튼이나 유사한 행동 유도 문구가 제공됩니다.

4.2 QR 코드 생성#

사용자 요청 시, 기기는 QR 코드 생성을 시작합니다. 이 QR 코드는 고유하고 시간 제한이 있는 세션 식별자를 인코딩합니다. 이 식별자는 인증 서버가 인증 프로세스 완료를 기다리는 동안 일시적으로 유지하는 세션에 연결됩니다.

4.3 QR 코드 스캔#

사용자는 패스키를 사용할 수 있는 기기로 이 QR 코드를 스캔합니다. 보안 조치는 다음과 같습니다:

일회용: QR 코드 내의 세션 식별자는 단일 사용에만 유효하여 재전송 공격을 방지합니다.
암호화: QR 코드 내의 모든 데이터는 암호화되어 가로채진 통신이 무단으로 해독될 수 없도록 보장합니다.

스캔된 QR 코드는 FIDO 스킴을 가진 특정 URI를 보유합니다. 예: FIDO:/07824133892604070278923969472008301099476228966286113051476699183587 6383562063181103169246410435938367110394959927031730060360967994421 343201235185697538107096654083332

4.4 데이터 흐름 및 인증 프로세스 시작#

QR 코드를 스캔하면 사용자의 두 번째 기기(예: 스마트폰 또는 태블릿)가 FIDO URI를 해석하고 인증 서버와 통신하여 사용자가 새 기기(예: 친구의 노트북)를 통해 인증을 시도하고 있다는 신호를 보냅니다. 이 작업은 서버가 이 인증 시도에 고유한 암호화 챌린지를 생성하도록 유도합니다.

4.5 기술 데이터 전송#

챌린지는 패스키가 저장된 사용자의 두 번째 기기(예: 스마트폰 또는 태블릿)로 다시 전송됩니다. 그런 다음 기기는 개인 키가 기기를 떠나지 않고(예: 스마트폰 또는 태블릿) 패스키와 관련된 개인 키를 사용하여 디지털 서명을 생성합니다. 서명된 챌린지(서명)는 인터넷을 통해 안전하고 암호화된 터널을 통해 서버로 다시 전송되어 인증 시도의 무결성과 출처를 확인합니다.

4.6 서명 검증#

서버는 이미 사용자 계정과 연결된 해당 공개 키를 사용하여 서명을 검증합니다. 성공적으로 검증되면 서버는 인증을 확인하고 사용자가 새 기기에서 서비스에 접근할 수 있도록 허용합니다.

고려해야 할 몇 가지 더 중요한 개인 정보 보호 및 보안 측면:

블루투스 데이터 교환 없음, 순수 인터넷: 이 QR 코드 기반 패스키 크로스 플랫폼 인증(하이브리드 전송)에서는 데이터 교환에 블루투스가 관여하지 않는다는 점에 유의하는 것이 중요합니다. 이 프로세스는 기기와 서버 간의 암호화된 데이터 전송을 위해 전적으로 인터넷 연결에 의존합니다. 그러나 블루투스는 두 기기의 근접 확인에 사용됩니다.
개인 키는 기기를 떠나지 않음: 이 과정 내내 사용자의 개인 키는 기기에 안전하게 남아 있습니다.
민감한 데이터 노출 없음: 인증 과정에서 민감한 패스키 정보나 개인 키가 전송되거나 노출되지 않습니다.
비대칭 암호화: 챌린지-응답 메커니즘은 전송되는 것이 무단 접근에 악용될 수 없는 재사용 불가능한 서명된 버전의 챌린지임을 보장합니다.

이러한 기술 및 보안 프로토콜을 준수함으로써 QR 코드 방식의 패스키 크로스 플랫폼 인증(하이브리드 전송)은 사용자가 새 기기에서 자신의 신원을 편리하게 인증할 수 있는 방법을 제공하면서 높은 수준의 보안을 유지합니다.

5. 패스키: 블루투스(caBLE)#

QR 코드 스캔 프로세스 외에도 블루투스(caBLE)를 통한 근접 확인도 있습니다. 클라이언트와 인증자가 물리적으로 서로 가깝다는 것을 확인하는 것은 WebAuthn 프로토콜의 주요 이점 중 하나입니다. 이 프로세스의 내부 작동에 대한 자세한 내용은 다음과 같습니다:

5.1 인증에서 블루투스 저전력(BLE)이란 무엇인가?#

**블루투스 저전력(BLE)**은 단거리 데이터 교환을 위해 설계된 무선 통신 기술입니다. 인증 과정에서 기기의 물리적 근접성을 확인하는 데 중추적인 역할을 합니다.

5.2 caBLE(클라우드 지원 블루투스 저전력)이란 무엇인가?#

caBLE은 BLE를 사용하여 기기 간에 인증 정보를 안전하게 전송하는 것을 용이하게 하는 프로토콜입니다. 패스키 크로스 플랫폼 인증(하이브리드 전송)에 caBLE를 사용할 때, 패스키를 보유한 기기는 BLE 신호를 통해 요청하는 기기의 근접성을 확인합니다. 근접성이 확인되면 인증 프로세스가 진행되며, 안전한 로컬 통신을 위해 BLE를 활용합니다.

5.3 caBLE를 사용한 사용자 경험 및 보안#

이 방법은 일반적으로 사용자의 직접적인 상호 작용이 덜 필요하기 때문에 사용자 경험이 향상됩니다. 물리적으로 가까운 거리에 있는 기기들이 서로를 자동으로 감지합니다. 보안 측면에서 caBLE은 상당한 이점을 제공합니다. 두 기기가 서로 가까이 있을 때만 인증 프로세스가 수행되도록 보장하여 원격 공격자가 인증 프로세스를 시작하는 것을 방지합니다.

5.4 시나리오: QR 코드 대 BLE 딜레마#

악성 사이트로 리디렉션되는 QR 코드를 받았다고 상상해 보십시오. 이 QR 코드를 통해 인증이 수행되면 세션이나 쿠키가 탈취될 위험이 있습니다. BLE는 시각적 스캔에 의존하지 않고 기기의 물리적 존재에 의존함으로써 이 문제를 우회합니다. 이 근접 확인은 인터넷이나 시각적 매체를 통해 발생하지 않으므로 중간자 공격의 위험을 최소화합니다.

5.5 데이터 교환 및 개인 정보 보호#

다른 방법과 달리 caBLE는 실제로 패스키와 같은 인증 데이터를 교환하지 않습니다. 대신, 기기가 물리적으로 가깝다는 것을 확인하기 위한 확인 채널로 BLE를 사용합니다. 이 확인은 BLE 근접성이 요소 중 하나인 다단계 인증 프로세스의 일부로 설계되어, 다른 요소가 손상되더라도 물리적 근접성 없이는 접근이 허용되지 않도록 보장합니다.

caBLE 프로토콜을 통합함으로써 개발자는 인증 프로세스의 전반적인 보안을 강화하는 안전하고 사용자 친화적인 패스키 크로스 플랫폼 인증(하이브리드 전송) 방법을 제공할 수 있습니다. 근접 확인은 사용자에게는 간단하면서도 특정 유형의 정교한 사이버 공격에 대해 효과적으로 보호하는 추가적인 보호 계층을 추가합니다.

6. 장점#

이 패스키 크로스 플랫폼 인증(하이브리드 전송) 방법의 장점은 다음과 같습니다:

6.1 좋은 사용자 경험으로 가는 길#

QR 코드와 블루투스(하이브리드 전송)를 통한 크로스 플랫폼 패스키 인증은 아무런 가능성을 제공하지 않는 것에 비해 크로스 플랫폼 시나리오에서 UX를 개선하는 방법입니다. 그러나 사용자 흐름은 대부분의 사용자에게 완전히 새롭기 때문에, 기술에 익숙하지 않은 많은 사용자가 이 흐름을 처음 접했을 때 무슨 일이 일어나고 있는지 이해할 것으로 기대하지 않습니다. QR 코드 흐름을 도입하는 것과 유사한 유일한 경우는 WhatsApp Web이나 Discord와 같은 로그인 흐름에서 QR 코드가 사용되는 경우입니다(여기서는 기능이 다르지만). 따라서 분석된 QR 코드/블루투스(하이브리드 전송)를 통한 크로스 플랫폼 패스키 인증 프로세스는 크로스 플랫폼 시나리오에서 수동으로 자격 증명을 입력할 필요가 없으므로 사용자 노력을 최소화하지만, 여전히 전체 흐름은 대부분의 사용자에게 알려져 있지 않습니다.

6.2 강력한 보안#

패스키 크로스 플랫폼 인증(하이브리드 전송)의 보안은 고급 암호화 기술로 강화됩니다. 인증을 위해 QR 코드를 스캔하거나 블루투스 연결이 이루어지면, 암호화 챌린지와 응답은 의도된 기기만이 인증 프로세스를 성공적으로 완료할 수 있도록 보장합니다.

블루투스를 통한 근접 확인은 추가적인 보안 계층을 추가하여, 인증 시도가 보조 기기에 물리적으로 접근할 수 있는 사람에 의해 이루어지고 있음을 확인합니다.

6.3 패스키 무결성#

크로스 플랫폼 인증(하이브리드 전송) 과정에서 패스키는 중간 장치나 서버에 일시적으로 저장되지 않으므로, 전송 과정에서 패스키가 가로채지거나 유출될 위험을 방지합니다. 인증은 실시간으로 이루어지며, 패스키는 사용자의 기본 장치에 바인딩된 상태를 유지하여 무결성을 보존합니다.

6.4 피싱 방지#

QR 코드 및 블루투스 인증 방법은 본질적으로 피싱에 대한 보호를 제공합니다. 인증 프로세스에는 사용자의 신뢰할 수 있는 장치에 특정한 물리적 조치가 필요하기 때문에 사용자가 악성 사이트에 패스키를 제공하도록 속을 가능성이 적습니다.

QR 코드를 스캔하거나 블루투스를 통해 연결하는 과정은 일반적으로 신뢰할 수 있는 환경에서 발생하므로 사용자가 실수로 자격 증명을 손상시킬 가능성을 줄입니다.

7. 단점#

이 패스키 크로스 플랫폼 인증(하이브리드 전송) 방법의 단점은 다음과 같습니다:

7.1 사용자 친숙도 및 채택#

새로운 기술을 도입하면 특히 기술에 익숙하지 않은 사용자에게 혼란을 줄 수 있습니다. QR 코드와 블루투스(하이브리드 전송)를 통한 패스키 크로스 플랫폼 인증은 기존 인증 방법에서 크게 벗어난 것이므로 일부 사용자는 새로운 프로세스를 이해하기 어려워할 수 있으며, 이는 채택률을 늦출 수 있습니다. 그러나 우리는 사용자가 결국 익숙해질 것으로 예상하므로, 처음에는 변화가 더 어려울 수 있지만 시간이 지남에 따라 더 부드럽고 수용될 것입니다.

7.2 기기 기능에 대한 의존성#

패스키 크로스 플랫폼 인증(하이브리드 전송)의 성공은 사용자의 기기가 QR 코드를 스캔할 수 있는 카메라와 블루투스 기능과 같은 필요한 기능을 갖추고 있는지에 크게 의존합니다. 이러한 기능이 없는 구형 기기를 사용하는 사용자는 패스키 크로스 플랫폼 인증(하이브리드 전송)을 이용할 수 없으므로 하드웨어 제한에 따른 디지털 격차가 발생합니다.

7.3 일관성 없는 사용자 행동#

사용자 행동은 예측할 수 없으며, QR 코드 스캔이나 블루투스 활성화와 같은 특정 작업을 수행하도록 사용자에 의존하면 사용자 오류가 발생할 수 있습니다. 예를 들어, 블루투스는 페어링 문제, 검색 문제 및 보안 거래에 대한 무선 기술에 대한 일반적인 사용자 불신으로 인해 때때로 UX 문제로 간주될 수 있습니다.

7.4 개발자 적응#

개발자는 최신 인증 방법을 지원하기 위해 시스템을 지속적으로 업데이트하고 유지 관리해야 하는 과제에 직면합니다. 기존 시스템에 패스키 크로스 플랫폼 인증(하이브리드 전송)을 통합하려면 개발자가 새로운 표준을 파악하고, 새로운 API를 채택하고, 이전 버전과의 호환성을 보장해야 하므로 리소스 집약적이고 시간이 많이 소요될 수 있습니다.

7.5 새로운 패스키 생성#

iCloud 키체인과 같은 동기화된 클라우드 계정이나 비밀번호 관리자를 사용하지 않는 경우, 모든 새 기기 또는 후속 로그인 요청에 대해 새 패스키를 생성해야 합니다. 이는 사용자 경험에 복잡성을 더할 수 있으며, 사용자가 프로세스에 익숙하지 않거나 직관적으로 만들어지지 않은 경우 좌절감을 유발할 수 있습니다.

7.6 사용자 교육#

패스키 크로스 플랫폼 인증(하이브리드 전송)과 같은 새로운 보안 방법을 구현할 때는 사용자 교육이 본질적으로 필요합니다. 사용자가 QR 코드와 블루투스를 안전하게 사용하는 방법을 이해하도록 하려면 명확한 의사소통과 광범위한 고객 지원이 필요할 수 있습니다.

QR 코드와 블루투스(하이브리드 전송)를 통한 패스키 크로스 플랫폼 인증은 인증 기술의 상당한 발전을 보여주지만, 이러한 잠재적인 단점은 사용자 친화적인 디자인, 강력한 지원 시스템, 그리고 기존 방법에서 혁신적인 방법으로의 점진적이고 잘 전달된 전환의 필요성을 강조합니다. 모든 기술적 변화와 마찬가지로, 혁신의 이점과 과제의 균형을 맞추는 것이 성공적인 구현과 광범위한 사용자 수용의 핵심이 될 것입니다.

8. 실제 테스트: 하이브리드 전송 패스키 동작#

면책 조항: 다음 테스트에서는 하드웨어 보안 키(예: YubiKey)를 무시하고 기기에 내장된 플랫폼 인증자(예: Face ID, Touch ID, Windows Hello)만 사용합니다. 하드웨어 보안 키(예: YubiKey)의 경우, 전송(transports) 값은 예를 들어 usb 또는 nfc가 됩니다.

다음 기기/브라우저 조합과 Passkeys Debugger를 사용하여 동작을 테스트합니다. Android는 크로스 플랫폼 인증(하이브리드 전송) 클라이언트로 작동할 수 없으므로 고려하지 않습니다(위의 3.2 소프트웨어 요구 사항 표 참조):

동작을 테스트하기 위해 각 조합에 대해 다음 속성을 가진 새 패스키를 생성합니다:

userName: alex muller (이 테스트에 영향 없음)
authenticatorAttachment: platform (YubiKey와 같은 하드웨어 보안 키를 제외하기 위함)
residentKey: preferred (이 테스트에 영향 없음)
userVerification: preferred (이 테스트에 영향 없음)
attestation: none (이 테스트에 영향 없음)
hints: empty (아래 설명 참조)
usePRF: no (이 테스트에 영향 없음)

패스키를 성공적으로 생성한 후, allowCredentials WebAuthn 서버 속성의 입력을 수정하고 로그인 요청을 시작합니다. 패스키를 생성한 기기에서 패스키가 삭제된 상황을 모방하여, 기기/브라우저가 QR 코드/블루투스를 통해 패스키를 제공할 수 있는 다른 기기를 찾도록 합니다. 따라서 credential ID를 변경하고 값으로 CHANGED-ID를 할당하여 일치가 실패하도록 합니다. 또한, allowCredentials에 있는 WebAuthn 자격 증명의 transports 속성을 변경하고 각 기기/브라우저 조합에 대해 다음 값을 할당합니다:

transports: [internal, hybrid]: 패스키는 플랫폼 인증자(예: Face ID, Touch ID, Windows Hello) 또는 크로스 플랫폼 인증을 통해 사용할 수 있습니다.
transports: [internal]: 패스키는 플랫폼 인증자(예: Face ID, Touch ID, Windows Hello)에서만 사용할 수 있습니다.
transports 속성 설정 안 함: 제한을 두지 않는 기본 동작입니다.

WebAuthn 테스트 사이트에는 사용자 에이전트 힌트를 위한 새로운 WebAuthn Level 3 기능도 제공됩니다. 이 기능은 신뢰 당사자(relying party)가 로그인 요청을 가장 사용자 친화적인 방식으로 완료할 수 있는 방법에 대한 특정 가정을 가지고 있을 때 사용자 경험을 향상시킬 수 있습니다. 이 테스트에서는 아직 출시되지 않았으므로 이 기능을 무시했습니다. 자세한 내용은 사양을 참조하십시오.

8.1 Windows 11 23H2 + Chrome 119#

8.1.1 transports: [internal, hybrid]#

예상대로 로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하여 다른 기기에서 패스키를 사용하도록 제안합니다(시스템이 이 사용자에 대한 패스키가 존재함을 알고 있기 때문).

8.1.2 transports: [internal]#

상당히 혼란스럽게도, 내부 자격 증명만 허용했음에도 불구하고 여기에서도 QR 코드가 표시됩니다. 이 동작에 대한 타당한 이유를 찾을 수 없었습니다.

8.1.3 transports 속성 설정 안 함#

로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.

어떤 이유에서인지, 모달의 일부가 설치된 언어 중 하나인 독일어로 나타납니다.

8.1.4 빈 allowCredentials#

예상대로 모든 형태의 패스키 인증이 허용됩니다: Windows Hello, QR 코드, 알려진 기기 및 하드웨어 보안 키를 통해.

8.2 Windows 11 23H2 + Edge 119#

8.2.1 transports: [internal, hybrid]#

8.2.2 transports: [internal]#

상당히 혼란스럽게도, 내부 자격 증명만 허용했음에도 불구하고 여기에서도 QR 코드가 표시됩니다. 이 동작에 대한 타당한 이유를 찾을 수 없었습니다.

8.2.3 transports 속성 설정 안 함#

로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.

어떤 이유에서인지, 모달의 일부가 설치된 언어 중 하나인 독일어로 나타납니다.

8.2.4 빈 allowCredentials#

예상대로 모든 형태의 패스키 인증이 허용됩니다: Windows Hello, QR 코드, 알려진 기기 및 하드웨어 보안 키를 통해.

8.3 Windows 11 23H2 + Firefox 119#

패스키를 생성할 때 다음 오류가 발생했습니다(그래도 패스키는 생성됨):

error: TypeError: 'toJSON' called on an object that does not implement interface PublicKeyCredential.

8.3.1 transports: [internal, hybrid]#

8.3.2 transports: [internal]#

상당히 혼란스럽게도, 내부 자격 증명만 허용했음에도 불구하고 여기에서도 QR 코드가 표시됩니다. 이 동작에 대한 타당한 이유를 찾을 수 없었습니다.

8.3.3 transports 속성 설정 안 함#

로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.

어떤 이유에서인지, 모달의 일부가 설치된 언어 중 하나인 독일어로 나타납니다.

8.3.4 빈 allowCredentials#

예상대로 모든 형태의 패스키 인증이 허용됩니다: Windows Hello, QR 코드, 알려진 기기 및 하드웨어 보안 키를 통해.

8.4 macOS Ventura + Chrome 119#

8.4.1 transports: [internal, hybrid]#

예상대로 로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하여 다른 기기에서 패스키를 사용하도록 제안합니다(시스템이 이 사용자에 대한 패스키가 존재함을 알고 있기 때문). 또한, 알려진 기기 중 하나를 직접 선택하여 거기서 패스키를 사용할 수도 있습니다.

모달은 Windows의 Chrome 119에서의 것과 상당히 다릅니다.

8.4.2 transports: [internal]#

이는 예상된 동작입니다. 내부 패스키만 사용하도록 허용했지만 기기에서 내부 자격 증명을 찾을 수 없기 때문입니다(하이브리드 패스키 사용은 허용되지 않음). 이 단계에서 패스키 인증이 실패하며, 실제 구현에서는 대체 인증 방법을 제공해야 합니다.

8.4.3 transports 속성 설정 안 함#

로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다. 또한, 알려진 기기 중 하나를 직접 선택하여 거기서 패스키를 사용할 수도 있습니다.

모달은 Windows의 Chrome 119에서의 것과 상당히 다릅니다.

8.4.4 빈 allowCredentials#

예상대로 모든 형태의 패스키 인증이 허용됩니다: Touch ID, QR 코드, 알려진 기기 및 하드웨어 보안 키를 통해.

8.5 macOS Ventura + Safari 16.6#

8.5.1 transports: [internal, hybrid]#

8.5.2 transports: [internal]#

상당히 혼란스럽게도, 내부 자격 증명만 허용했음에도 불구하고 여기에서도 QR 코드가 표시됩니다. 이 동작에 대한 타당한 이유를 찾을 수 없었습니다.

8.5.3 transports 속성 설정 안 함#

로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.

8.5.4 빈 allowCredentials#

예상대로 대부분의 패스키 인증 형태가 허용됩니다: Touch ID, QR 코드 및 하드웨어 보안 키를 통해. 어떤 이유에서인지 알려진 기기는 표시되지 않습니다.

8.6 iOS 17.1 + Chrome 119#

8.6.1 transports: [internal, hybrid]#

8.6.2 transports: [internal]#

상당히 혼란스럽게도, 내부 자격 증명만 허용했음에도 불구하고 여기에서도 QR 코드가 표시됩니다. 이 동작에 대한 타당한 이유를 찾을 수 없었습니다.

8.6.3 transports 속성 설정 안 함#

로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.

8.6.4 빈 allowCredentials#

예상대로 대부분의 패스키 인증 형태가 허용됩니다: Face ID, QR 코드 및 하드웨어 보안 키를 통해. 어떤 이유에서인지 알려진 기기는 표시되지 않습니다.

8.7 iOS 17.1 + Safari 17.1#

8.7.1 transports: [internal, hybrid]#

8.7.2 transports: [internal]#

상당히 혼란스럽게도, 내부 자격 증명만 허용했음에도 불구하고 여기에서도 QR 코드가 표시됩니다. 이 동작에 대한 타당한 이유를 찾을 수 없었습니다.

8.7.3 transports 속성 설정 안 함#

로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.

8.7.4 빈 allowCredentials#

다음으로, Windows 10 기기의 경우 한 단계 더 나아가 블루투스가 비활성화되었거나 Windows 10 컴퓨터에서 일반적으로 사용할 수 없는 경우의 동작을 분석하기로 결정했습니다. 특히 구형 데스크톱 기기의 경우, 블루투스 모듈이 없는 경우가 많아 QR 코드와 블루투스를 통한 크로스 플랫폼 인증이 불가능한 매우 일반적인 시나리오입니다.

8.8 Windows 10 21H2 + Chrome 119#

8.8.1 블루투스 활성화됨#

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 블루투스 비활성화됨#

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 Windows 10 21H2 + Edge 119#

8.9.1 블루투스 활성화됨#

8.9.1.1 transports: [internal, hybrid]

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 블루투스 비활성화됨#

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 Windows 10 22H2 + Chrome 119#

8.10.1 블루투스 활성화됨#

8.10.1.1 transports: [internal, hybrid]

8.10.1.2 transports: [internal]

8.10.1.3 transports 속성 설정 안 함

로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.

8.10.1.4 빈 allowCredentials

8.10.2 블루투스 비활성화됨#

8.10.2.1 transports: [internal, hybrid]

사용자에게 무엇을 해야 하고 어떻게 인증할 수 있는지 명시적으로 설명하지 않기 때문에 매우 혼란스러운 메시지입니다. 유일한 옵션은 "취소"를 클릭하는 것이므로 이 시나리오는 막다른 길이 됩니다. 어떤 이유에서인지 Windows 보안 모달의 일부가 이 기기에 설치된 두 번째 언어인 독일어로 표시됩니다.

8.10.2.2 transports: [internal]

8.10.2.3 transports 속성 설정 안 함

로컬 패스키가 일치하지 않으므로, 유일한 옵션은 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하는 것입니다.

8.10.2.4 빈 allowCredentials

패스키 인증은 Windows Hello와 하드웨어 보안 키를 통해서만 가능합니다.

8.11 Windows 10 22H2 + Edge 119#

8.11.1 블루투스 활성화됨#

8.11.1.1 transports: [internal, hybrid]

8.11.1.2 transports: [internal]

8.11.1.3 transports 속성 설정 안 함

로컬 패스키가 일치하지 않으므로, QR 코드를 스캔하거나 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하도록 제안합니다.

8.11.1.4 빈 allowCredentials

8.11.2 블루투스 비활성화됨#

8.11.2.1 transports: [internal, hybrid]

8.11.2.2 transports: [internal]

8.11.2.3 transports 속성 설정 안 함

로컬 패스키가 일치하지 않으므로, 유일한 옵션은 하드웨어 보안 키(예: YubiKey) / 크로스 플랫폼 인증자 / 로밍 인증자를 사용하는 것입니다.

8.11.2.4 빈 allowCredentials

패스키 인증은 Windows Hello와 하드웨어 보안 키를 통해서만 가능합니다.

9. 개발자를 위한 권장 사항#

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

Try for Free

9.1 구현 팁#

순수 WebAuthn API의 복잡성 일부를 추상화하는 라이브러리 및 프레임워크를 사용하십시오.
광범위한 사용자 기반이 패스키 구현의 이점을 누릴 수 있도록 처음부터 크로스 플랫폼 인증 시나리오를 고려하십시오. 디자인 선택에 따라 이러한 시나리오에서 대체 로그인 방법을 제공할 수도 있습니다.
기기 제한으로 인해 패스키 크로스 플랫폼 인증(하이브리드 전송)이 불가능할 수 있는 시나리오에 대한 대체 메커니즘을 개발하십시오.
가장 큰 디자인 결정은 QR 코드/블루투스(하이브리드 전송)를 통한 크로스 플랫폼 패스키 인증을 장려하고 이를 패스키 인증의 주요 방법으로 만들 것인지, 아니면 힌트를 사용하여 적극적으로 홍보하지 않을 것인지를 결정하는 것입니다. 후자의 경우, 항상 내부적으로 저장된 패스키를 즉시 사용하려고 시도하고 내부 패스키가 없는 경우에만 크로스 플랫폼 인증(하이브리드 전송)을 위한 QR 코드가 표시됩니다. 이는 WebAuthn 서버 옵션의 excludeCredentials 및 allowCredentials 속성에서 정의해야 합니다. WebAuthn 서버의 excludeCredentials 속성에서는 이미 생성된 자격 증명에 대한 전송 정보를 볼 수 있습니다. allowCredentials 속성에서는 로그인 프로세스의 동작을 지정할 수 있습니다(위의 8. 실제 테스트: 하이브리드 전송 패스키 동작 참조).
또한, 크로스 플랫폼 패스키 인증(하이브리드 전송)을 완전히 막을 수는 없으므로(transports: [internal]을 사용한 위의 테스트 참조), 사용자가 이 방법을 발견하고 질문을 할 수 있다는 점에 대비해야 합니다. 이 크로스 플랫폼 인증(하이브리드 전송)은 특히 사용자가 로컬에서 패스키를 삭제하기 시작할 때 발생합니다.

9.2 교육 전략#

사용자에게 패스키 크로스 플랫폼 인증(하이브리드 전송) 프로세스를 안내하는 포괄적인 가이드와 튜토리얼을 만드십시오.
사용자가 처음으로 패스키 크로스 플랫폼 인증(하이브리드 전송)을 경험할 때 안내하기 위해 인앱 툴팁과 상황별 도움말 섹션을 사용하십시오.
웹사이트나 애플리케이션 내에 FAQ 및 문제 해결 섹션을 제공하십시오.

9.3 임시 접근 고려 사항#

QR 코드 또는 블루투스를 통한 패스키 로그인에 대해 시간 제한이 있는 세션을 구현하여 접근이 일시적이고 안전하도록 보장하십시오.
패스키 크로스 플랫폼 인증(하이브리드 전송)이 기존 보안 프로토콜을 약화시키지 않고 사용자 데이터의 무결성을 유지하도록 하십시오.
개인 정보 보호 영향을 고려하고 패스키 크로스 플랫폼 인증(하이브리드 전송)을 통해 부여된 모든 임시 접근이 보안 모범 사례에 따라 기록되고 모니터링되도록 하십시오.

10. 결론: QR 코드 / 블루투스 패스키#

QR 코드/블루투스(하이브리드 전송)를 통한 패스키 크로스 플랫폼 인증은 보안과 UX 사이의 균형을 제공합니다. 그러나 대부분의 사용자에게는 완전히 새로운 프로세스이며 많은 혼란스러운 상황을 유발할 수 있으므로 이를 홍보할지 신중하게 생각해야 합니다.

이 글을 통해 QR 코드/블루투스를 통한 패스키 크로스 플랫폼 인증(하이브리드 전송) 주제에 대해 약간의 빛을 비추고, 설정 방법과 다양한 기기/브라우저 조합에서의 동작을 설명할 수 있었기를 바랍니다. 질문이 있으시면 패스키 커뮤니티를 통해 문의하시거나 패스키 Substack을 구독해 주세요. 패스키를 널리 알려 인터넷을 더 안전한 곳으로 만듭시다.