패스키는 비밀번호 대신 공개키 암호를 사용하는 FIDO 자격 증명입니다. 사이트는 등록 때 공개키를 저장합니다. 로그인 assertion의 서명 입력은 challenge 문자열만이 아닙니다. 인증기는 자격 증명 개인키로 authenticatorData || clientDataHash를 서명하며, clientDataHash는 직렬화된 clientDataJSON의 SHA-256입니다. challenge와 origin은 clientDataJSON에 포함되고, RP ID 해시는 authenticatorData에 담깁니다. 서버는 각 값을 별도로 검증하고 등록된 공개키로 서명을 확인합니다. 개인키 자체는 서비스로 보내지 않습니다. W3C WebAuthn Level 3의 서명 데이터 설명을 참조하세요. FIDO Alliance 패스키 안내는 동기화형과 기기 종속형의 차이를 설명합니다.

로그인 assertion은 challenge가 포함된 데이터를 서명한다

등록 시 서비스(Relying Party)는 브라우저에 자격 증명 생성을 요청하고, 인증기는 키 쌍을 만들며 공개키 자격 증명을 반환합니다. 서비스는 계정과 연결된 credential ID, 공개키 등 검증에 필요한 정보를 저장합니다. 로그인 때 서버가 새 challenge를 보내면 인증기는 사용자 확인 뒤 서명 결과를 돌려줍니다. 서버는 challenge와 출처(origin), RP ID 등 검증 항목을 확인하고 공개키 서명을 검증합니다. 생체정보나 PIN 자체를 서비스가 받는 로그인 방식은 아닙니다.

동기화 여부와 discoverable 여부는 다른 축

동기화형 패스키는 같은 제공자의 계정에 연결된 다른 기기에서도 사용할 수 있도록 동기화될 수 있습니다. 기기 종속형(device-bound)은 등록된 인증기에 묶이며 기기를 잃으면 복구가 어려울 수 있습니다. FIDO Alliance의 배포 안내는 동기화형이 기기 교체·분실 후 접근성을 높이는 반면, 제공자 계정이나 호환성에 문제가 생기면 복구가 여전히 필요할 수 있다고 설명합니다.

WebAuthn의 discoverable credential은 로그인 때 사이트가 먼저 credential ID를 제시하지 않아도 인증기나 플랫폼에서 자격 증명을 찾을 수 있는지에 관한 용어입니다. 이전의 resident key라는 이름이 이 특성을 가리킵니다. 반면 backup-eligible/multi-device와 single-device는 자격 증명이 백업·동기화될 수 있는지에 관한 구분입니다. 따라서 discoverable 또는 resident라고 해서 반드시 특정 기기에만 묶였다고 결론 내릴 수 없습니다.

서비스 운영자가 저장·검증할 것

서비스는 각 로그인마다 추측하기 어려운 challenge를 발급하고 재사용을 거부해야 합니다. 서명 확인 외에도 응답의 origin과 요청한 RP ID가 기대한 사이트와 일치하는지 검증합니다. credential ID와 공개키는 계정에 연결해 저장하되, 기기 라벨이나 생성 시각 같은 관리정보를 사용자에게 보여 주면 어떤 수단을 등록했는지 관리하기 쉽습니다. 구현은 WebAuthn 라이브러리와 브라우저 API 문서를 따라야 하며, 단순히 서명 형식만 확인하는 것으로는 충분하지 않습니다.

복구를 등록 시점에 설계하기

새 기기나 제공자 환경으로 옮길 가능성이 있으면 사용자가 접근할 수 있는 두 번째 패스키나 별도 계정 복구 절차를 미리 마련하세요. 동기화형도 제공자 계정에 접근하지 못하거나 새 기기가 제공자를 지원하지 않으면 사용할 수 없을 수 있습니다. 기기 종속형만 허용하는 서비스는 등록 추가와 기기 분실 시 복구 경로를 더 명확히 안내해야 합니다. FIDO 자료는 동기화 여부와 무관하게 대체 인증·복구 수단을 검토하도록 권합니다.

참고 자료