WebAuthn Signal API：クライアントサイドでパスキーを更新・削除する

Looking for a dev-focused passkey reference? Download our Passkeys Cheat Sheet. Trusted by dev teams at Ally, Stanford CS & more.

Get Cheat Sheet

最終更新日：2025年11月4日

各プラットフォームにおける WebAuthn Signal API のサポート状況の概要は以下の通りです。

⚠️ 既知の問題： Safari 26+ には、Promise が正しく解決されないバグがあります（WebKit Bug #298951）。修正のマージ待ちです。

パスキーのエコシステムは日々進化しています。変化に対応するため、基盤となる WebAuthn 標準も急速に発展しています。新機能は多くの場合、GitHub 上の技術的な Explainer（解説書）として始まり、十分な議論を経て標準規格へのプルリクエスト（PR）として提案されます。最近、このプルリクエストが、WebAuthn Signal APIとして標準ドラフトに追加されました。この記事では、以下の点について見ていきます。

• WebAuthn Signal API がなぜ必要なのか： どのようなユースケースをサポートしているのか？
• WebAuthn Signal API はどのように機能するのか： 具体的な仕組みと、Relying Party (RP) への推奨事項は？

執筆時点では、WebAuthn Signal API は Chrome 132 以降でデフォルトで有効になっています。以前は Reporting API と呼ばれていましたが、別のAPIとの名前の競合を避けるために名称が変更されました。

WebAuthn Signal API は、クライアントサイドでのパスキー管理に関する特定のユースケースに対応します。具体的には、Relying Party (RP) と、クライアントサイドの OS に組み込まれた認証器 (Authenticator) との間で情報の同期を保つのに役立ちます。主に以下の2つの重要なユースケースがあります。

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: これらは、ユーザーインターフェース（UI）で表示するためだけに使用されるメタデータです。

以下の図は、どの情報がどのフィールドに保存されるかを示す一般的なデータベース構造の例です。

ここで理解しておくべき重要な点は、user.name（多くの場合メールアドレス）や user.displayName（読みやすい表示名）はユーザーが自分のアカウントを識別するのを助けるためのものですが、パスキーとアカウントの本当の紐付けは user.id と Credential ID によって管理されているということです。

• 1つのアカウントに複数のパスキーを持たせることはできますが、各パスキーは user.id を使ってアカウントと一意に照合されます。
• 各パスキー自体は、認証器によって生成されたユニークな Credential ID を持っています。

問題になるのは、メールアドレスなどの user.name が変更された場合です。現在、クライアントサイドの認証器上の情報を直接更新する仕組みはありません。ユーザーがメールアドレスを変更するなど、user.name は様々な理由で変わる可能性があります。サーバー側でアカウントのメタデータが変更されても、認証器の選択画面には古い user.name が表示され続け、ユーザーの混乱を招く原因となります。

これまでの回避策（ワークアラウンド）は、同じ user.id で更新された user.name を持つ新しいパスキーを作成し、既存のパスキーを上書きすることでした。しかし、この方法はいくつかの理由で不便です。

1. 冗長性： 認証器は、特定の RP ID に対して user.id ごとに1つのパスキーしか保存できません。つまり、メタデータを更新するためだけに古いパスキーを新しいものに置き換える必要があり、余計な手間がかかります。
2. ユーザー体験 (UX)： ユーザーは、なぜ新しいパスキーを作成する必要があるのか理解できません。これが、この回避策が広く普及していない理由です。
3. 複雑さ： メタデータを更新するためだけにパスキーの作成や置き換えを管理するのは、不必要な複雑さを招きます。

メールアドレスや電話番号などの識別子は定期的に変わる可能性があります。user.name や user.displayName を認証器上で直接更新する簡単な方法がないと、ユーザーは古いメールアドレスに関連付けられたパスキーを見せられ、それを選択しなければならないという永続的な問題に直面します。これでは、パスキーが目指すシームレスな体験が損なわれてしまいます。WebAuthn Signal API は、新しいパスキーを作成することなく、RP がパスキーのメタデータの更新を通知（Signal）できるようにすることで、この問題を解決しようとしています。

実装方法を解説する前に、もう一つの重要なユースケースを見てみましょう。

Become part of our Passkeys Community for updates & support.

Join

もう一つの重要なユースケースは、クライアントサイドの認証器からのパスキーの削除です。時が経つにつれて、ユーザーがパスキー管理リストから認証情報を無効化したり、アカウント自体を削除したりすることがあります。そのような場合、将来の認証情報選択 UI（Conditional UI / パスキーの自動入力）に表示されないように、クライアントサイドの認証器からも確実に削除する必要があります。

この機能は、以下のようなシナリオで必要になります。

1. アカウント設定からのパスキー削除： ユーザーがアカウント設定から明示的に削除した場合など、認証情報が有効でなくなった場合。

ユーザーの視点からすると、上記のようなダイアログでアカウント設定から削除を行っても、このクライアント（端末）上のパスキーまでは削除されないというのは理解しにくい挙動です。

2. アカウントの削除： ユーザーがアカウントを削除した場合、関連するすべてのパスキーも削除されるべきです。
3. セキュリティポリシー： RP によっては、一定期間の非アクティブ状態や、セキュリティ上の問題が検知された後に認証情報を無効化するポリシーを持っている場合があります。

クライアントサイドでパスキーを直接削除する方法がないと、これらの古くなったり無効になったりした認証情報が選択 UI に残り続け、混乱を招きます。ユーザーが無効なパスキーを使おうとして認証に失敗するなど、UX の低下につながります。

Corbado Connect 管理コンソールでサーバーサイドのパスキーを削除する方法については、こちらの動画をご覧ください。

WebAuthn Signal API の実装には、機能が正しく安全に統合されるようにするためのいくつかのステップと考慮事項があります。Signal API を使用すると、Relying Party (RP) はクライアントサイドの認証器上のパスキー認証情報を更新または削除できます。ここでは、実装のための重要なポイントと手順を解説します。

WebAuthn Signal API を実装する際は、以下の点に注意することが重要です。

• プライバシーの保護： WebAuthn Signal API は、WebAuthn の基盤の一つであるユーザーのプライバシーを保護するように設計されています。つまり、要求された変更が処理されたかどうかについて、RP にフィードバックは返されません。API は、認証情報の状態に関する情報漏洩を防ぐために、サイレント（静的）に動作します。
• 認証器の可用性： WebAuthn Signal API の有効性は、認証器が利用可能かどうかに依存します。これには物理的な可用性とソフトウェアのサポート（ブラウザや OS の互換性など）の両方が含まれます。ブラウザは、認証器がアクセス可能であり、かつ生体認証を必要とせずに必要な操作をサポートしている場合にのみアクションを実行できます。
• ドメイン制限： API は、特定のドメインに関連付けられた RP だけが、そのドメインに関連する認証情報の変更を要求できるようにします。これは、第三者による不正な変更を防ぐためのセキュリティ対策です。
• キーとしての Credential ID： パスキーを参照する際、Credential ID が WebAuthn Signal API で使用される主キーとなります。この ID は、クライアントサイドの認証器上のパスキーを一意に識別します。API を使用して RP はパスキーに関連するメタデータを変更したり、特定のパスキーにアクセスできないようにしたりできますが、これは Credential ID を通じてのみ行われます。認証器が特定の Credential ID を知らない場合、その要求は単に無視されます。

これらの考慮事項は、WebAuthn Signal API を正しく機能させるために不可欠な要素です。

WebAuthn Signal API は、RP がクライアントサイドの認証器上のパスキーに関連付けられたメタデータを更新するための合理的なメカニズムを提供します。これは、不必要に新しいパスキーを作成することなく、ユーザーが認証情報選択 UI で正確かつ最新の情報を確認できるようにするために特に重要です。

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", // ユーザーハンドル、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 の一部であり、デスクトップ版の Google パスワード マネージャーでテストできます。

WebAuthn Signal API は、RP がクライアントサイドの認証器からパスキーの削除を通知（シグナル）する仕組みも提供します。これは、古くなったり無効になった認証情報が選択 UI に表示されないようにし、スムーズで安全なユーザー体験を維持するために不可欠です。ローカルでパスキーを削除するには、signalUnknownCredential(options) と signalAllAcceptedCredentials(options) の2つのメソッドがあります。前者はユーザーが認証されていない状況で使用でき、後者はユーザーが認証されている場合に使用できます。したがって、プライバシーの観点からは後者（signalAllAcceptedCredentials）が推奨されます。

それぞれの仕組みは以下の通りです。

1. メソッドの構造： signalUnknownCredential(options) メソッドには、rpId（Relying Party ID）と credentialId（削除対象の認証情報の一意な識別子）が含まれます。

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc", // ユーザーが試行したばかりの credential id、base64url
});

2. メソッドの呼び出し： RP は、認証情報を削除すべきだと判断したときにこのメソッドを呼び出します。これは、無効な認証情報による認証試行の直後、アカウント削除時、またはユーザーがアカウント設定から認証情報を無効化した際などが考えられます。
3. メソッドの処理： signalUnknownCredential(options) メソッドが呼び出されると、クライアントサイドの認証器は rpId と credentialID に一致する認証情報を探し、除外対象とします。認証器の機能に応じて、認証情報は削除されるか、将来の認証セレモニーで非表示にするための認証器固有の手順が実行されます。

1. メソッドの構造： signalAllAcceptedCredentials(options) メソッドには、rpId、userId、および有効な Credential ID のリストである allAcceptedCredentialIds（保持すべき認証情報のユニークIDのリスト）が含まれます。

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "aabbcc", // ユーザーハンドル、base64url
    allAcceptedCredentialIds: ["bb"],
});

2. メソッドの呼び出し： RP は、削除すべき認証情報を検知した際にこのメソッドを呼び出し、有効な認証情報のリストを通知します。認証情報を削除する場合、signalUnknownCredential(options) よりもこのメソッドの使用が推奨されます。
3. メソッドの処理： signalAllAcceptedCredentials(options) メソッドが呼び出されると、クライアントサイドの認証器は rpId と userId を照合します。認証器は rpId と userId に一致するすべてのローカル認証情報を検索し、その結果を allAcceptedCredentialIds と比較します。allAcceptedCredentialIds に含まれていないローカル認証情報がある場合、それらはローカルで削除されます（または認証器によっては非表示になります）。
4. 認証情報の再表示（Unhide）： 認証情報が単に非表示にされていただけで（認証器の仕様による）、後に allAcceptedCredentialIds に含まれるようになった場合、その認証情報は再び将来の認証セレモニーで表示されるようになります。
5. 役立つヒント：
   • signalAllAcceptedCredentials(options) を使用する際、このメソッドが実行される時点で認証器が常に接続されているとは限らないことに注意してください。そのため、RP はサインインのたびに signalAllAcceptedCredentials(options) を実行するなど、定期的に実行してすべての認証情報を最新の状態に保つことを検討すべきです。
   • RP は Credential ID のリスト（allAcceptedCredentialIds）を指定する際、注意が必要です。このリストに含まれていない認証情報は、認証器によって不可逆的に削除または非表示にされる可能性があります。有効な認証情報が誤って除外されないよう、リストが完全であることを確認してください。もし有効な Credential ID が誤って漏れていた場合は、できるだけ早く signalAllAcceptedCredentials(options) に再度追加して、再び表示されるようにする必要があります（認証器がこれをサポートしている場合）。
   • 可能であれば、認証器は認証情報を完全に削除するのではなく、一時的に非表示にすることを優先すべきです。このアプローチにより、RP が誤って有効な Credential ID を除外してしまった場合でも、永久的な損失なしに復元しやすくなります。

上のスクリーンショットでは、Google Chrome が削除をどのように通知しているかがわかります。WebAuthn Signal API は、デスクトップ版の Google パスワード マネージャーでテスト可能です。

WebAuthn Signal API を効果的に実装し、クライアントサイドの認証器全体でパスキーのメタデータをシームレスに同期させるために、以下の推奨事項を検討してください。

• WebAuthn Signal API の更新情報と実際の実装状況を注視する： Signal API に関連する最新の開発状況や更新情報を常にチェックしてください。WebAuthn Signal API は Google Chrome 132 で有効化されており、他のブラウザもそれに続いています（例：Safariもサポートを表明）。WebAuthn Signal API の進捗と更新を定期的に確認し、実装が最新の標準や慣行に沿っていることを確認しましょう。このブログ記事も状況の変化に合わせて更新していく予定です。
• ログイン成功後は毎回 signalAllAcceptedCredentials(options) を実行するアプローチから始める： このアプローチにより、1つのメソッドですべてのメタデータと Credential ID が更新され、プロセスが簡素化されます。また、デバイスやプラットフォーム間での一貫性が保たれると同時に、削除されたり古くなったりした認証情報を無効化できます。
• 大規模な展開では signalUnknownCredential(options) によるリアルタイムメッセージングを活用する： 大規模な展開や即時更新が必要な場合は、signalUnknownCredential(options) メソッドを使用したリアルタイムでの通知を検討してください。この方法は、認証情報管理の効率と正確性を高め、無効または古い認証情報が選択 UI から即座に削除されることを保証します。

これらの推奨事項に従うことで、サポートが整い次第 WebAuthn Signal API を効果的に実装でき、すべてのクライアントサイド認証器でパスキーのメタデータを最新かつ一貫した状態に保つことができます。これにより、パスキーによるスムーズで安全なユーザー体験を提供できます。

WebAuthn 標準は継続的に進化しており、毎月のように機能が充実してきています。WebAuthn Signal API の導入は、クライアントサイドの認証器におけるパスキーのメタデータ管理と削除において、大きな前進と言えます。この API は、RP と認証器の間で情報を同期し、無効または古いパスキーを確実に削除するという重要なユースケースに対応しており、ユーザー体験を向上させます。

• なぜ Signal API が必要なのか？ Signal API は、クライアントサイドの認証器でパスキーのメタデータを更新し、パスキーを削除するために不可欠です。これにより、認証情報選択 UI で混乱を招く原因となる古い user.name や user.displayName の問題を解決します。さらに、無効化または削除されたパスキーを削除することで、クリーンで安全な認証情報選択画面を維持するのに役立ちます。
• Signal API はどのように機能するのか？ Signal API は、RP がメタデータの更新やパスキー削除の通知など、認証情報の現在の状態に関するメソッドを呼び出すことで機能します。これらの通知はクライアントサイドの認証器によって処理され、ユーザーに提示される情報が正確かつ最新であることを保証します。API はプライバシーを保護するように設計されており、更新の成功可否について RP にフィードバックを提供することなく動作します。

WebAuthn 標準が進化するにつれて、参加者の多様な関心によって標準の様々な部分が推進されるという恩恵を受けています。最新の拡張機能に追随し、実装が最新のベストプラクティスや標準に沿っていることを確認するためには、こうした動向に注目し続けることが重要です。WebAuthn コミュニティはイノベーションを推進し続け、認証をより安全でユーザーフレンドリーなものにしています。