신뢰 당사자를 위한 패스키 개발자 가이드

서비스에 패스키를 통합하는 방법을 알아보세요.

패스키 시스템의 구조

패스키 시스템은 다음과 같은 몇 가지 구성요소로 구성됩니다.

  • 신뢰 당사자: 패스키 컨텍스트에서 신뢰 당사자 (RP)는 패스키 발급 및 인증을 처리합니다. RP는 클라이언트(패스키를 생성하거나 패스키로 인증하는 웹사이트 또는 앱)와 클라이언트의 패스키로 생성된 사용자 인증 정보를 등록, 저장, 확인하는 서버를 운영해야 합니다. 패스키 모바일 애플리케이션은 디지털 애셋 링크와 같은 OS 제공 연결 메커니즘을 사용하여 RP 서버 도메인에 바인딩되어야 합니다.
  • Authenticator: 운영체제에서 제공하는 화면 잠금 기능을 사용하여 패스키를 생성하고 확인할 수 있는 컴퓨팅 기기(예: 휴대전화, 태블릿, 노트북, 데스크톱 컴퓨터)입니다.
  • 비밀번호 관리자: 최종 사용자의 기기에 설치되어 패스키를 제공, 저장, 동기화하는 소프트웨어입니다(예: Google 비밀번호 관리자).

등록 흐름

웹사이트에서 WebAuthn API를 사용하거나 Android 앱에서 Credential Manager 라이브러리를 사용하여 새 패스키를 만들고 등록합니다.

새 패스키를 만들려면 몇 가지 주요 구성요소를 제공해야 합니다.

  • RP ID: 신뢰 당사자의 ID를 웹 도메인 형식으로 제공합니다.
  • 사용자 정보: 사용자의 ID, 사용자 이름, 표시 이름입니다.
  • 제외할 사용자 인증 정보: 중복 등록을 방지하기 위해 이전에 저장된 패스키에 관한 정보입니다.
  • 패스키 유형: 기기 자체 ('플랫폼 인증자')를 인증자로 사용할지 아니면 분리 가능한 보안 키 ('크로스 플랫폼 / 로밍 인증자')를 사용할지 여부입니다. 또한 호출자는 사용자가 로그인할 계정을 선택할 수 있도록 사용자 인증 정보를 검색 가능하게 할지 여부를 지정할 수 있습니다.

RP가 패스키 생성을 요청하고 사용자가 화면 잠금으로 이를 확인하면 새 패스키가 생성되고 공개 키 사용자 인증 정보가 반환됩니다. 이를 서버로 전송하고 향후 인증을 위해 사용자 인증 정보 ID와 공개 키를 저장합니다.

등록 흐름

패스키를 생성하고 등록하는 방법을 자세히 알아보세요.

인증 흐름

웹사이트에서 WebAuthn API를 사용하거나 Android 앱에서 Credential Manager 라이브러리를 사용하여 등록된 패스키로 인증합니다.

패스키로 인증하려면 다음과 같은 몇 가지 주요 구성요소를 제공해야 합니다.

  • RP ID: 신뢰 당사자의 ID를 웹 도메인 형식으로 제공합니다.
  • 챌린지: 재전송 공격을 방지하는 서버 생성 챌린지입니다.

RP가 패스키로 인증을 요청하고 사용자가 화면 잠금 해제로 인증하면 공개 키 사용자 인증 정보가 반환됩니다. 이를 서버로 전송하고 저장된 공개 키로 서명을 확인합니다.

인증 흐름

패스키로 인증하는 방법을 자세히 알아보세요.

서버 측 통합

패스키를 만들 때 서버는 챌린지, 사용자 정보, 제외할 인증 정보 ID 등의 키 매개변수를 제공해야 합니다. 그런 다음 클라이언트에서 전송된 생성된 공개 키 사용자 인증 정보를 확인하고 데이터베이스에 공개 키를 저장합니다. 패스키로 인증하려면 서버에서 사용자 로그인 허용을 위해 인증 정보를 신중하게 검증하고 서명을 확인해야 합니다.

서버 측 가이드에서 자세히 알아보세요.

기존 (레거시) 인증 메커니즘

기존 서비스에서 패스키를 지원하는 경우 비밀번호와 같은 이전 인증 메커니즘에서 패스키로의 전환이 하루 만에 이루어지지는 않습니다. 약한 인증 방법을 최대한 빨리 없애고 싶으시겠지만, 그렇게 하면 사용자가 혼란스러워하거나 일부 사용자가 소외될 수 있습니다. 당분간은 기존 인증 방법을 유지하는 것이 좋습니다.

몇 가지 이유가 있습니다.

  • 패스키와 호환되지 않는 환경의 사용자가 있음: 패스키 지원이 여러 운영체제와 브라우저로 광범위하게 확대되고 있지만 이전 버전을 사용하는 사용자는 아직 패스키를 사용할 수 없습니다.
  • 패스키 생태계가 아직 성숙하지 않음: 패스키 생태계는 진화하고 있습니다. 다양한 환경 간의 UX 세부정보와 기술적 호환성이 개선될 수 있습니다.
  • 사용자가 아직 패스키를 사용할 준비가 되지 않았을 수 있음: 새로운 것을 시도하는 데 주저하는 사용자가 있습니다. 패스키 생태계가 성숙해짐에 따라 패스키의 작동 방식과 패스키가 유용한 이유를 알게 됩니다.

기존 인증 메커니즘 재검토

패스키를 사용하면 인증이 더 간단하고 안전해지지만 기존 메커니즘을 유지하는 것은 구멍을 남기는 것과 같습니다. 기존 인증 메커니즘을 다시 검토하고 개선하는 것이 좋습니다.

비밀번호

사용자에게는 안전한 비밀번호를 만들고 각 웹사이트에 대해 관리하는 것이 어려운 작업입니다. 시스템에 내장된 비밀번호 관리자나 독립형 비밀번호 관리자를 사용하는 것이 좋습니다. 로그인 양식을 약간만 조정하면 웹사이트와 앱의 보안과 로그인 환경에 큰 차이를 만들 수 있습니다. 다음에서 변경하는 방법을 확인하세요.

이중 인증

비밀번호 관리자를 사용하면 사용자가 비밀번호를 처리하는 데 도움이 되지만 모든 사용자가 비밀번호 관리자를 사용하는 것은 아닙니다. 이러한 사용자를 보호하기 위해 일회용 비밀번호(OTP)라는 추가 사용자 인증 정보를 요청하는 것이 일반적인 방법입니다. OTP는 일반적으로 이메일, SMS 메시지 또는 Google OTP와 같은 인증 앱을 통해 제공됩니다. OTP는 일반적으로 제한된 시간 범위 내에서만 유효한 동적으로 생성된 짧은 텍스트이므로 계정 도용 가능성이 낮아집니다. 이러한 방법은 패스키만큼 강력하지는 않지만 사용자에게 비밀번호만 남겨두는 것보다는 훨씬 낫습니다.

OTP를 전송하는 방법으로 SMS를 선택하는 경우 다음 권장사항을 확인하여 OTP를 입력하는 사용자 환경을 간소화하세요.

ID 제휴

ID 제휴는 사용자가 안전하고 쉽게 로그인할 수 있는 또 다른 옵션입니다. ID 제휴를 사용하면 웹사이트와 앱에서 사용자가 서드 파티 ID 공급업체의 사용자 ID를 사용하여 로그인할 수 있습니다. 예를 들어 Google 계정으로 로그인은 개발자에게 높은 전환율을 제공하며, 사용자는 비밀번호 기반 인증보다 더 쉽고 선호하는 것으로 생각합니다. ID 제휴는 패스키를 보완합니다. 웹사이트나 앱이 한 단계로 사용자의 기본 프로필 정보를 얻을 수 있으므로 가입에 적합하며, 패스키는 재인증을 간소화하는 데 적합합니다.

2024년에 Chrome에서 서드 파티 쿠키를 단계적으로 중단한 후 일부 ID 연동 시스템은 구축 방식에 따라 영향을 받을 수 있습니다. 이러한 영향을 완화하기 위해 Federated Credential Management API (줄여서 FedCM)라는 새로운 브라우저 API가 개발되고 있습니다. ID 공급업체를 운영하는 경우 세부정보를 확인하여 FedCM을 채택해야 하는지 알아보세요.

매직 링크 로그인은 서비스가 이메일을 통해 로그인 링크를 전송하여 사용자가 링크를 클릭하여 자신을 인증할 수 있도록 하는 인증 방법입니다. 이렇게 하면 사용자가 비밀번호를 기억하지 않고도 로그인할 수 있지만 브라우저/앱과 이메일 클라이언트 간에 전환하는 데 불편함이 있습니다. 또한 인증 메커니즘이 이메일을 기반으로 하므로 이메일 제공업체의 보안이 취약하면 사용자 계정이 위험에 처할 수 있습니다.

학습 리소스

웹

웹사이트에 패스키를 통합하려면 Web Authentication API(WebAuthn)를 사용하세요. 자세한 내용은 다음 리소스를 참고하세요.

Android

Android 앱에 패스키를 통합하려면 인증 관리자 라이브러리를 사용하세요. 자세한 내용은 다음 리소스를 참고하세요.

UX

패스키 사용자 환경 권장사항 알아보기: