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

패스키를 서비스에 통합하는 방법을 알아봅니다.

패스키 시스템 분석

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

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

등록 절차

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

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

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

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

등록 절차

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

인증 흐름

등록된 패스키로 인증하려면 웹사이트의 WebAuthn API 또는 Android 앱의 인증 관리자 라이브러리를 사용합니다.

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

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

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

인증 흐름

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

서버 측 통합

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

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

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

기존 서비스에서 패스키를 지원하면 비밀번호와 같은 이전 인증 메커니즘에서 패스키로 전환하는 작업은 하루 안에 이루어지지 않습니다. Google은 개발자가 최대한 빨리 취약한 인증 방법을 제거하려는 경향이 있다는 것을 알고 있지만 이로 인해 사용자에게 혼란을 야기하거나 일부 사용자가 이탈할 수 있습니다. 당분간 기존 인증 방법을 유지하는 것이 좋습니다.

여기에는 다음과 같은 몇 가지 이유가 있습니다.

  • 패스키 호환되지 않는 환경에 사용자가 있음: 패스키 지원은 여러 운영체제와 브라우저에서 광범위하게 확장되고 있지만 이전 버전을 사용하는 사용자는 아직 패스키를 사용할 수 없습니다.
  • 패스키 생태계는 아직 성숙하지 않음: 패스키 생태계가 진화하고 있습니다. 서로 다른 환경 간의 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

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