WebAuthn은 웹사이트가 비밀번호 대신 공개키 자격 증명으로 사용자를 인증하도록 브라우저와 인증기 사이의 절차를 정의합니다. passkey는 이 표준 절차를 이용하는 자격 증명 경험이며, 사이트는 등록된 공개키를 보관하고 인증기는 개인키를 이용해 서명합니다. 실제 구현에서는 개인키가 인증기나 동기화 서비스를 통해 관리될 수 있으므로, 특정 기기에만 절대적으로 묶인다고 단정해서는 안 됩니다.

1. 등록 과정에서 사이트와 인증기가 나누는 역할

계정 등록 때 서버는 challenge와 relying party 정보를 브라우저에 전달합니다. 브라우저는 사용자의 동작과 정책에 따라 기기 내장 인증기, 보안 키 등 사용할 수 있는 인증기를 호출합니다. 인증기는 사용자 존재 확인과 설정된 경우 사용자 검증을 수행하고, 새 자격 증명에 대응하는 공개키 정보를 돌려줍니다. 서버는 응답을 검증하고 credential ID 및 공개키를 계정에 연결해 저장합니다.

사이트가 저장하는 공개키는 다음 로그인 서명을 검증하는 데 사용됩니다. 등록 challenge는 일회성 값으로 관리하고, origin과 relying party ID 등 절차의 맥락을 확인해야 합니다. 브라우저와 인증기가 API 호출을 수행한다고 해서 서버 검증을 생략할 수 있는 것은 아닙니다. 등록 응답은 서버에서 challenge, origin, 자격 증명 데이터와 정책을 확인한 뒤에만 신뢰해야 합니다.

2. 로그인 assertion과 challenge 검증

로그인할 때 서버는 새 challenge를 발급하고 브라우저가 기존 자격 증명으로 assertion을 요청하게 합니다. 브라우저는 challenge를 포함한 clientDataJSON을 만들고 그 SHA-256 해시를 인증기에 전달합니다. 인증기는 authenticator data와 이 해시를 이어 붙인 데이터에 해당 개인키로 서명하며, 따라서 서명 대상은 challenge 바이트만이 아닙니다. 서버는 저장된 공개키로 서명을 검증하고 challenge가 최신이며 해당 세션에 속하는지 확인합니다. challenge가 재사용되거나 origin과 relying party가 예상과 다르면 성공으로 처리하면 안 됩니다.

이 과정에서 자격 증명 ID는 인증기에 연결된 키를 찾는 식별자 역할을 합니다. 사용자 존재(user presence) 확인과 사용자 검증(user verification)은 다른 의미입니다. 전자는 사용자가 인증 절차에 참여했음을, 후자는 PIN 또는 생체인식 등 인증기 수준의 검증이 수행되었음을 나타낼 수 있습니다. 서비스는 두 개념과 계정 위험 정책을 구분해 필요한 수준을 요청해야 합니다.

3. passkey 동기화와 복구의 현실적인 범위

passkey는 플랫폼에 따라 여러 기기에서 사용할 수 있도록 동기화될 수 있고, 보안 키처럼 별도 인증기에 보관되는 자격 증명도 있습니다. 표준은 사이트와 인증기 사이의 프로토콜을 정의하지만, 각 공급자의 동기화·백업·계정 복구 방식을 하나로 규정하지 않습니다. 사용자에게는 계정 복구 수단, 새 기기 등록, 분실한 기기의 자격 증명 철회 경로를 함께 설계해야 합니다.

공개키 인증은 비밀번호 재사용을 줄일 수 있지만, 계정 복구와 기기 생태계의 위험을 없애지는 않습니다. 사용자가 모든 인증기를 잃었을 때 어떤 증거로 계정을 복구할지, 복구 후 기존 credential을 어떻게 폐기할지 사전에 결정해야 합니다. 지원 환경과 passkey 이동 가능성은 플랫폼 설정에 따라 다르므로 “기기 하나를 잃으면 로그인 불가” 또는 “모든 기기에서 자동 복구”라고 일반화하지 않습니다.

4. 배포 전 보안·운영 점검

W3C 명세는 브라우저가 중개하는 생성·인증 ceremony와 검증 데이터의 의미를 규정합니다. MDN의 Web Authentication 안내는 개발자가 이 API를 공개키 등록과 인증에 적용하는 큰 흐름을 이해하도록 설명합니다. 두 자료 모두 서버 측 검증을 대신하는 제품 코드가 아니므로, 서비스는 challenge 생성·수명·일회성, origin 및 RP ID 일치, credential 상태, 사용자 확인 정책을 자체 인증 로직에서 점검해야 합니다.

실제 배포에서는 HTTPS와 허용된 origin에서 등록 및 로그인 흐름을 시험하고, 지원되지 않는 브라우저의 대체 로그인과 계정 복구도 확인합니다. 로그에는 민감한 인증 응답 전체나 비밀 재료를 저장하지 말고, 실패 원인을 보안 검증·사용자 취소·기능 비지원으로 구분합니다. passkey는 암호 없는 인증을 가능하게 하지만, 계정 복구·세션 관리·접근 제어까지 자동으로 해결해 주지는 않습니다.

출처