WebAuthn

비밀번호는 사용자가 기억하고 입력할 수 있다는 장점이 있지만, 그 편의가 곧 약점이기도 합니다. 사람들은 같은 비밀번호를 여러 사이트에 재사용하고, 피싱 페이지에 속아 직접 입력하기도 하며, 서버에 저장된 해시가 유출되면 오프라인 대입 공격 대상이 됩니다. 문자 OTP 같은 보조 수단도 프록시 피싱 앞에서는 충분히 안전하지 않은 경우가 있습니다. 결국 문제는 '사용자가 알고 있는 비밀'에 지나치게 의존한다는 데 있습니다. 사이트가 정말 이 사용자와 대화하고 있다는 것을, 복사되기 쉬운 문자열이 아니라 장치 안에 묶인 자격 증명으로 증명할 방법이 필요해졌습니다.

FIDO 연합과 브라우저 벤더들은 오랫동안 비밀번호 없는 로그인 방식을 표준화하려고 시도했습니다. USB 보안 키와 플랫폼 생체인증 장치가 늘어나면서, 브라우저가 공통 API로 이런 인증기를 다룰 수 있어야 한다는 요구가 분명해졌습니다. WebAuthn은 CTAP과 함께 FIDO2 생태계의 웹 표준 층을 담당합니다. 브라우저가 인증기와 사이트 사이의 중재자 역할을 하고, 서버는 공개키와 origin 검증만으로 로그인 여부를 판단할 수 있게 되면서, 비밀번호 중심 인증 모델을 대체할 현실적인 길이 열린 것입니다.

등록 단계에서는 서버가 일회용 챌린지를 만들고 브라우저에 전달합니다. 브라우저는 이 요청을 인증기에게 넘기고, 인증기는 현재 사이트의 origin과 챌린지를 바탕으로 새로운 공개키/개인키 쌍을 만듭니다. 공개키와 credential ID는 서버에 저장되고, 개인키는 장치 밖으로 나오지 않습니다. 로그인 단계에서는 서버가 다시 새로운 챌린지를 보냅니다. 사용자가 지문, 얼굴, PIN, 보안 키 터치 같은 방식으로 본인 확인을 하면, 인증기는 그 챌린지에 개인키로 서명합니다. 서버는 저장해 둔 공개키로 서명을 검증해 사용자를 확인합니다. 핵심은 서명이 현재 사이트의 origin에 묶여 있다는 점입니다. 사용자가 비슷하게 꾸민 피싱 사이트에 들어가더라도, origin이 다르면 같은 자격 증명이 성립하지 않습니다. 그래서 WebAuthn은 비밀번호보다 피싱 저항성이 훨씬 높습니다.

WebAuthn과 OAuth는 모두 로그인 화면 근처에서 자주 보이지만 푸는 문제가 다릅니다. WebAuthn은 현재 사이트가 사용자의 신원을 직접 확인하는 인증 방식이고, OAuth는 다른 서비스에 권한을 위임하는 절차입니다. 본인 확인과 권한 위임을 구분해야 혼동이 줄어듭니다. JWT와도 성격이 다릅니다. WebAuthn은 로그인 순간에 사용자를 증명하는 방법이고, JWT는 로그인 이후 요청마다 인증 상태를 전달하는 토큰 형식입니다. 즉 WebAuthn은 '어떻게 로그인했는가', JWT는 '로그인 후 상태를 어떻게 실어 나르는가'에 가깝습니다.

WebAuthn은 패스키 기반 로그인, 관리자용 강한 2단계 인증, 계정 탈취 위험이 큰 금융·업무 시스템에서 특히 유용합니다. 사용자가 비밀번호를 외우지 않아도 되면서, 피싱과 재사용 문제를 동시에 줄일 수 있기 때문입니다. 실무에서는 기기 교체와 복구 흐름을 꼭 함께 설계해야 합니다. 등록된 장치를 잃어버렸을 때 계정을 어떻게 되찾을지 준비하지 않으면, 보안은 좋아져도 운영 부담이 급격히 커집니다. 한편 너무 쉽게 복구를 열어 두면 WebAuthn을 붙인 의미가 약해집니다. 또 WebAuthn만으로 로그인 세션이 유지되는 것은 아닙니다. 로그인 순간의 강한 본인 확인 뒤에는 여전히 세션이나 토큰을 어떻게 운영할지 결정해야 합니다. 그래서 WebAuthn 도입은 기존 인증 체계를 버리는 일이 아니라, 그 첫 관문을 훨씬 강하게 바꾸는 일에 가깝습니다.