WebAuthn Signal API: 클라이언트 측에서 패스키 업데이트 및 삭제하기

패스키 생태계는 계속해서 발전하고 있습니다. 이러한 변화를 촉진하기 위해 기반이 되는 WebAuthn 표준도 빠르게 진화하고 있습니다. 새로운 기능은 종종 GitHub의 기술 설명서(technical explainer)에서 시작하여 충분한 논의를 거친 후 표준에 대한 풀 리퀘스트(pull request)로 발전합니다. 최근에는 이 풀 리퀘스트가 표준 초안에 WebAuthn Signal API로 추가되었습니다. 이 글에서는 다음 내용을 다룰 것입니다.

• WebAuthn Signal API가 필요한 이유: WebAuthn Signal API는 어떤 사용 사례를 지원할까요?
• WebAuthn Signal API의 작동 방식: WebAuthn Signal API는 정확히 어떻게 작동할까요? Relying Party를 위한 권장 사항은 무엇일까요?

2025년 1월에 이 블로그 게시물을 업데이트하는 시점에서, WebAuthn Signal API는 Chrome 132부터 기본적으로 활성화되어 있습니다. 이전에는 Reporting API로 알려졌으나, 동일한 이름의 다른 API와의 충돌을 피하기 위해 이름이 변경되었습니다.

WebAuthn Signal API는 클라이언트 측에서 패스키를 관리하는 특정 사용 사례를 다룹니다. 특히, Relying Party(RP)와 클라이언트 측 운영 체제의 일부인 인증자 간의 정보를 동기화하는 데 도움을 줍니다. 다음과 같은 중요한 사용 사례가 있습니다.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

패스키가 생성될 때 user.id, user.name, user.displayName 등 여러 정보가 포함됩니다. 패스키 자체는 고유한 Credential ID를 통해 식별됩니다.

• user.id: 패스키가 연결된 계정을 나타내는 고유 식별자입니다. 이 user.id는 패스키를 사용자 계정과 실제로 일치시키는 데 사용되므로 매우 중요합니다.
• user.name 및 user.displayName: 이들은 사용자 인터페이스에서 표시 목적으로만 사용되는 메타데이터입니다.

다음 그림은 어떤 정보가 일반적으로 어떤 필드에 저장되는지 설명하는 일반적이고 간단한 데이터베이스 구조를 보여줍니다.

user.name(주로 이메일 주소)과 user.displayName(더 친숙하고 읽기 쉬운 이름)이 사용자가 선택 UI에서 자신의 계정을 식별하는 데 도움이 되지만, 패스키와 계정 간의 실제 연결은 user.id와 **Credential ID**를 통해 유지된다는 점을 이해하는 것이 중요합니다.

• 하나의 계정은 여러 개의 패스키를 가질 수 있지만, 각 패스키는 user.id를 사용하여 고유하게 식별되고 계정과 일치됩니다.
• 모든 패스키 자체에는 인증자가 생성한 고유한 Credential ID가 있습니다.

이메일 주소일 수 있는 user.name이 변경될 때 문제가 발생합니다. 현재로서는 이 변경 사항을 클라이언트 측 인증자에서 직접 업데이트할 메커니즘이 없습니다. user.name은 사용자가 이메일 주소를 업데이트하는 등 다양한 이유로 변경될 수 있습니다. 서버 측에서 계정의 메타데이터가 변경되었음에도 불구하고, 이전 user.name이 자격 증명 선택 UI에 계속 표시되어 사용자에게 혼란을 줄 수 있습니다.

이 문제에 대한 해결책은 업데이트된 user.name과 동일한 user.id로 새 패스키를 생성한 다음 기존 패스키를 덮어쓰는 것입니다. 하지만 이 방법은 여러 가지 이유로 불편합니다.

1. 중복성: 각 user.id는 Relying Party ID당 하나의 패스키만 가질 수 있으므로, 이전 패스키를 새 것으로 교체해야 하는 추가 단계가 필요합니다.
2. 사용자 경험: 사용자는 왜 새 패스키를 만들어야 하는지 이해하지 못할 것입니다. 이것이 이 해결책이 널리 사용되지 않는 이유입니다.
3. 복잡성: 단순히 메타데이터를 업데이트하기 위해 패스키 생성 및 교체를 관리하는 것은 불필요한 복잡성을 야기합니다.

이메일 주소, 전화번호 및 기타 식별자는 정기적으로 변경될 수 있습니다. user.name과 user.displayName을 인증자에서 직접 업데이트할 간단한 방법이 없다면, 사용자는 이전 이메일 주소와 연결된 패스키를 보고 선택해야 하는 지속적인 문제에 직면할 수 있습니다. 이러한 상황은 패스키가 제공하고자 하는 원활한 경험을 저해합니다. WebAuthn Signal API는 Relying Party가 새 패스키를 생성할 필요 없이 패스키의 메타데이터 업데이트를 보고할 수 있도록 하여 이 문제를 해결하는 것을 목표로 합니다. Signal API 구현 방법을 설명하기 전에, 이 API가 해결하는 두 번째 중요한 사용 사례를 살펴보겠습니다.

Become part of our Passkeys Community for updates & support.

Join

또 다른 중요한 사용 사례는 클라이언트 측 인증자에서 패스키를 삭제하는 것입니다. 시간이 지남에 따라 사용자는 패스키 관리 목록을 통해 자격 증명을 취소하거나 계정을 삭제할 수 있으며, 이러한 자격 증명이 향후 자격 증명 선택 UI(Conditional UI / 패스키 자동 완성)에 나타나지 않도록 클라이언트 측 인증자에서 제거되도록 해야 합니다.

이 기능의 필요성은 여러 시나리오에서 발생합니다.

1. 계정 설정을 통한 패스키 삭제: 사용자가 계정 설정을 통해 명시적으로 자격 증명을 삭제한 후와 같이 더 이상 유효하지 않은 경우:

사용자 입장에서는 위와 같은 대화 상자에서 계정 설정을 삭제해도 이 클라이언트에서 패스키가 제거되지 않는다는 점을 이해하기 어렵습니다.

2. 계정 삭제: 사용자가 계정을 삭제하면 모든 관련 패스키도 제거되어야 합니다.
3. 보안 정책: Relying Party는 비활성 기간이 지나거나 감지된 보안 문제로 인해 자격 증명을 취소해야 하는 보안 정책을 가질 수 있습니다.

클라이언트 측에서 패스키를 직접 삭제하는 방법이 없으면, 오래되거나 유효하지 않은 이러한 자격 증명이 선택 UI를 계속 복잡하게 만들어 혼란을 야기합니다. 사용자는 더 이상 유효하지 않은 패스키를 보고 사용하려고 시도할 수 있으며, 이는 인증 실패와 좋지 않은 사용자 경험으로 이어집니다.

WebAuthn Signal API를 구현하려면 기능이 정확하고 안전하게 통합되도록 몇 가지 단계와 고려 사항이 필요합니다. Signal API를 통해 Relying Party(RP)는 클라이언트 측 인증자에서 패스키 자격 증명을 업데이트하거나 삭제할 수 있습니다. 이 섹션에서는 구현을 위한 주요 고려 사항과 단계를 간략하게 설명합니다.

WebAuthn Signal API를 구현할 때 다음 고려 사항을 염두에 두는 것이 중요합니다.

• 개인 정보 보호: WebAuthn Signal API는 WebAuthn의 기본 원칙 중 하나인 사용자 개인 정보 보호를 위해 설계되었습니다. 즉, 요청된 변경 사항이 처리되었는지 여부에 대해 RP에게 피드백이 제공되지 않습니다. API는 자격 증명 상태에 대한 정보 유출 가능성을 방지하기 위해 조용히 작동합니다.

• 인증자 가용성: WebAuthn Signal API의 효과는 인증자의 가용성에 따라 달라집니다. 여기에는 물리적 가용성(예: 보안 키의 존재)과 소프트웨어 지원(예: 브라우저 및 운영 체제 호환성)이 모두 포함됩니다. 브라우저는 인증자에 접근할 수 있고 생체 인증 없이 필요한 작업을 지원하는 경우에만 작업을 수행할 수 있습니다.

• 도메인 제한: API는 특정 도메인과 관련된 Relying Party만이 해당 도메인과 관련된 자격 증명 변경을 요청할 수 있도록 보장합니다. 이는 제3자에 의한 무단 수정을 방지하기 위한 보안 조치입니다.

• Credential ID를 키로 사용: 패스키를 참조할 때 Credential ID는 WebAuthn Signal API에서 사용하는 기본 키입니다. 이 ID는 클라이언트 측 인증자에서 패스키를 고유하게 식별합니다. API를 통해 RP는 패스키와 관련된 메타데이터를 변경하거나 특정 패스키에 더 이상 접근해서는 안 된다고 신호를 보낼 수 있지만, 이는 Credential ID를 통해서만 가능합니다. 인증자가 특정 Credential ID를 모르는 경우, 조용히 무시합니다.

이러한 고려 사항은 WebAuthn Signal API가 올바르게 작동하는 가장 중요한 측면을 이해하는 데 필수적입니다.

WebAuthn Signal API는 Relying Party(RP)가 클라이언트 측 인증자에서 패스키와 관련된 메타데이터를 업데이트할 수 있는 간소화된 메커니즘을 제공합니다. 이는 사용자가 불필요하게 새 패스키를 만들지 않고도 자격 증명 선택 UI에서 정확하고 최신 정보를 볼 수 있도록 하는 데 특히 중요합니다. API가 이를 가능하게 하는 방법은 다음과 같습니다.

signalCurrentUserDetails(options)로 메타데이터 업데이트

Signal API의 signalCurrentUserDetails(options) 메서드는 패스키의 메타데이터를 업데이트하기 위해 특별히 설계되었습니다. 이 메서드를 통해 RP는 user.name과 user.displayName의 현재 값을 제공할 수 있습니다.

프로세스는 다음과 같이 작동합니다(WebAuthn Level 3 표준 참조).

1. 메서드 구조: signalCurrentUserDetails(options) 메서드에는 rp.id, user.id 및 user.name과 user.displayName의 업데이트된 값이 포함됩니다.

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    name: "New user name",
    displayName: "New display name",
});

2. 로컬 메타데이터 업데이트: rpId 및 userId와 일치하는 로컬(인증자)에서 사용 가능한 자격 증명을 찾습니다. 일치하는 모든 자격 증명에 대해 인증자는 자격 증명의 name과 displayName을 업데이트합니다.

3. 개인 정보 보호: 이 프로세스는 개인 정보를 보호하도록 설계되었습니다. Signal API는 업데이트가 성공적으로 처리되었는지 여부에 대한 피드백을 RP에게 제공하지 않으므로 자격 증명 상태에 대한 정보 유출을 방지합니다.

4. 기기 간 일관성: signalCurrentUserDetails(options) 메서드를 정기적으로 실행함으로써 RP는 사용자가 인증할 수 있는 여러 다른 기기 및 플랫폼에서 패스키의 메타데이터가 일관되게 유지되도록 할 수 있습니다. 이 접근 방식은 오래되거나 잘못된 정보가 자격 증명 선택 UI에 표시될 가능성을 줄입니다.

위 스크린샷에서 Google Chrome이 사용자에게 이러한 업데이트를 어떻게 신호하는지 볼 수 있습니다. WebAuthn Signal API는 Chrome 130의 일부이며, 실험적인 웹 기능 플래그가 활성화된 경우 데스크톱의 Google 비밀번호 관리자로 테스트할 수 있습니다.

WebAuthn Signal API는 Relying Party(RP)가 클라이언트 측 인증자에서 패스키 삭제를 신호할 수 있는 메커니즘을 제공합니다. 이는 오래되거나 유효하지 않은 자격 증명이 자격 증명 선택 UI에 나타나지 않도록 하여 간소화되고 안전한 사용자 경험을 유지하는 데 필수적입니다. 패스키를 로컬에서 삭제하는 방법에는 signalUnknownCredential(options)와 signalAllAcceptedCredentials(options) 두 가지가 있습니다. 전자는 사용자가 인증되지 않은 상황에서 사용할 수 있고, 후자는 사용자가 인증된 경우에 사용할 수 있습니다. 따라서 개인 정보 보호를 위해 후자를 선호해야 합니다.

두 메서드가 작동하는 방식은 다음과 같습니다.

1. 메서드 구조: signalUnknownCredential(options) 메서드에는 rpId(Relying Party ID)와 credentialId(삭제할 자격 증명의 고유 식별자)가 포함됩니다.

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc", // credential id the user just tried, base64url
});

2. 메서드 호출: RP는 자격 증명을 삭제해야 한다고 감지할 때마다 이 메서드를 호출합니다. 이는 유효하지 않은 자격 증명으로 인증을 시도한 직후, 계정 삭제 중 또는 사용자가 계정 설정을 통해 자격 증명을 취소할 때일 수 있습니다.

3. 메서드 처리: signalUnknownCredential(options) 메서드가 호출되면 클라이언트 측 인증자는 rpId와 credentialID가 지정된 자격 증명을 찾아 생략을 시도합니다. 인증자의 기능에 따라 자격 증명이 제거되거나 향후 인증 절차에서 자격 증명을 숨기는 인증자별 절차가 사용됩니다.

1. 메서드 구조: signalAllAcceptedCredentials(options) 메서드에는 rpId(Relying Party ID), userId 및 유효한 Credential ID 목록인 allAcceptedCredentialIds(유지해야 할 자격 증명의 고유 식별자 목록)가 포함됩니다.

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    allAcceptedCredentialIds: ["bb"],
});

2. 메서드 호출: RP는 자격 증명을 삭제해야 한다고 감지하고 유효한 자격 증명 목록을 신호할 때마다 이 메서드를 호출합니다. 이 메서드는 자격 증명을 삭제하기 위해 signalUnknownCredential(options)보다 선호되어야 합니다.

3. 메서드 처리: signalAllAcceptedCredentials(options) 메서드가 호출되면 클라이언트 측 인증자는 rpId와 userId를 일치시킵니다. 인증자는 rpId와 userId와 일치하는 모든 로컬 자격 증명을 조회합니다. 결과는 allAcceptedCredentialIds와 비교됩니다. allAcceptedCredentialIds에 없는 로컬 자격 증명이 있는 경우, 이러한 자격 증명은 로컬에서 제거됩니다(또는 인증자에 따라 숨겨짐).

4. 자격 증명 숨기기 해제: 자격 증명이 (인증자에 따라) 숨겨져 있었지만 이제 allAcceptedCredentialIds의 일부가 된 경우, 이러한 자격 증명은 향후 인증 절차에 다시 표시됩니다.

5. 유용한 팁:

   • signalAllAcceptedCredentials(options)를 사용할 때 이 메서드가 실행될 때 인증자가 항상 연결되어 있지 않을 수 있다는 점에 유의하는 것이 중요합니다. 결과적으로 Relying Party는 모든 자격 증명이 최신 상태인지 확인하기 위해 로그인할 때마다 signalAllAcceptedCredentials(options)를 주기적으로 실행하는 것을 고려할 수 있습니다.
   • Relying Party는 자격 증명 ID 목록(allAcceptedCredentialIds)을 지정할 때 주의해야 합니다. 이 목록에 포함되지 않은 자격 증명은 인증자에 의해 숨겨지거나 제거될 수 있으며, 잠재적으로 되돌릴 수 없습니다. 유효한 자격 증명이 실수로 누락되는 것을 방지하려면 목록이 완전한지 확인하는 것이 중요합니다. 유효한 자격 증명 ID가 실수로 누락된 경우, 인증자가 이를 지원한다고 가정하면 다시 표시되도록 가능한 한 빨리 signalAllAcceptedCredentials(options)에 다시 추가해야 합니다.
   • 가능하면 인증자는 자격 증명을 영구적으로 제거하는 대신 일시적으로 숨기는 것을 선호해야 합니다. 이 접근 방식은 Relying Party가 실수로 유효한 자격 증명 ID를 누락한 경우 복구를 용이하게 하여 영구적인 손실 없이 복원할 수 있도록 도와줍니다.

위 스크린샷에서 Google Chrome이 삭제를 신호하는 방법을 볼 수 있습니다. WebAuthn Signal API는 Chrome 132의 일부이며 데스크톱의 Google 비밀번호 관리자로 테스트할 수 있습니다.

WebAuthn Signal API를 효과적으로 구현하고 클라이언트 측 인증자에서 패스키 메타데이터의 원활한 동기화를 보장하려면 다음 권장 사항을 고려하십시오.

• WebAuthn Signal API 업데이트 및 실제 구현에 주의: Signal API와 관련된 최신 개발 및 업데이트에 대한 정보를 계속 확인하십시오. WebAuthn Signal API는 Google Chrome 132에서 활성화되었으며, 다른 브라우저(예: Safari도 지원 발표)가 뒤따를 것입니다. WebAuthn Signal API의 진행 상황과 업데이트를 정기적으로 확인하여 구현이 최신 표준 및 관행과 일치하는지 확인하십시오. 이 블로그 게시물은 2025년 1월 14일 현재 사용 가능한 정보를 기반으로 하며, 향후 업데이트될 예정입니다.
• 매 성공적인 로그인 후 signalAllAcceptedCredentials(options) 접근 방식으로 시작: 이 접근 방식은 모든 메타데이터와 자격 증명 ID가 단일 메서드로 업데이트되도록 보장하여 프로세스를 단순화하고 기기 및 플랫폼 간의 일관성을 유지하며 동시에 삭제되거나 오래된 자격 증명을 비활성화합니다.
• 대규모 배포를 위한 signalUnknownCredential(options)을 사용한 실시간 메시징: 대규모 배포나 즉각적인 업데이트가 필요한 경우 signalUnknownCredential(options) 메서드를 사용한 실시간 메시징을 고려하십시오. 이 방법은 자격 증명 관리의 효율성과 정확성을 향상시켜 유효하지 않거나 오래된 자격 증명이 선택 UI에서 신속하게 제거되도록 보장합니다.

이러한 권장 사항을 따르면 WebAuthn Signal API가 지원될 때 효과적으로 구현하여 패스키 메타데이터가 모든 클라이언트 측 인증자에서 최신 상태와 일관성을 유지하도록 보장하고, 이를 통해 패스키에 대한 원활하고 안전한 사용자 경험을 제공할 수 있습니다.

WebAuthn 표준은 지속적으로 발전하며 매월 더 많은 기능을 갖추게 됩니다. WebAuthn Signal API의 도입은 클라이언트 측 인증자에서 패스키 메타데이터 및 삭제를 관리하는 데 있어 중요한 진전입니다. 이 API는 Relying Party(RP)와 인증자 간의 정보를 동기화하고 유효하지 않거나 오래된 패스키를 제거하여 사용자 경험을 개선하는 중요한 사용 사례를 해결합니다.

• Signal API가 필요한 이유는 무엇인가요? Signal API는 클라이언트 측 인증자에서 패스키 메타데이터를 업데이트하고 패스키를 삭제하는 데 필수적입니다. 오래된 user.name 및 user.displayName 정보와 관련된 문제를 해결하여 자격 증명이 선택 UI에 표시될 때 혼란을 줄 수 있습니다. 또한, 취소되거나 삭제된 패스키를 제거하여 깨끗하고 안전한 자격 증명 선택 인터페이스를 유지하는 데 도움이 됩니다.
• Signal API는 어떻게 작동하나요? Signal API는 RP가 메타데이터 업데이트 및 패스키 삭제 신호를 포함하여 자격 증명의 현재 상태에 대한 메서드를 호출할 수 있도록 하여 작동합니다. 이러한 보고서는 클라이언트 측 인증자에 의해 처리되어 사용자에게 제공되는 정보가 정확하고 최신 상태인지 확인합니다. API는 개인 정보를 보호하도록 설계되었으며 업데이트 성공 여부에 대한 피드백을 RP에게 제공하지 않고 작동합니다.

WebAuthn 표준이 발전함에 따라, 표준의 여러 부분을 발전시키는 다양한 참여자들의 관심사로부터 이점을 얻습니다. 이러한 발전에 주목하는 것은 최신 개선 사항을 파악하고 구현이 최신 모범 사례 및 표준과 일치하도록 보장하는 데 중요합니다. WebAuthn 커뮤니티는 계속해서 혁신을 주도하여 인증을 더욱 안전하고 사용자 친화적으로 만들고 있습니다.