WebAuthnクライアント機能

WebAuthnは、パスキーを支える最新の標準技術です。従来のパスワードに頼る代わりに、公開鍵暗号方式を活用し、ユーザーが生体認証（指紋や顔認証など）や物理的なセキュリティキーを含むパスキーで認証できるようにします。この変化は、セキュリティを強化するだけでなく、パスワード管理の必要性をなくすことでユーザーエクスペリエンスも向上させます。

WebAuthnレベル3標準では、開発者やプラットフォームがパスキーを実装する際により多くの制御と柔軟性を提供することを目的とした、新しいクライアント機能（ブラウザAPI getClientCapabilities() を介して取得可能）が導入されています。これらのアップデートにより、デバイス、ブラウザ、プラットフォーム間でのパスキーの統合プロセスが簡素化され、よりスムーズで一貫したユーザー体験が保証されます。

このブログ記事では、以下の質問に答えていきます。

1. WebAuthnクライアント機能とは何か？
2. どのようなWebAuthnクライアント機能が存在するのか？
3. WebAuthnクライアント機能はパスキーの実装をどのように改善するのか？
4. WebAuthnクライアント機能はなぜ開発者とプロダクトマネージャーの両方にとって重要なのか？

最後まで読めば、これらの機能が現代のユーザーの期待に沿った、シームレスで安全な認証フローを作成するのにどのように役立つかを理解できるでしょう。

WebAuthnクライアント機能とは、ブラウザやプラットフォームがどの種類のWebAuthn機能をサポートしているかを伝えるための一連の機能です。簡単に言えば、ウェブサイトにユーザーのデバイスで利用可能な認証方法や設定を知らせる「機能のチェックリスト」のような役割を果たします。これにより、開発者はクライアントの機能に基づいて認証フローを調整し、よりスムーズで安全なユーザーエクスペリエンスを確保できます。

例えば、ブラウザが生体認証（Touch IDなど）をサポートしていることを示した場合、開発者はユーザーに指紋でのログインオプションを提供するようにログインフローを設計できます。逆に、ブラウザが特定の機能をサポートしていない場合、開発者はパスワードやSMS OTPなどの代替オプションを提供できます。

WebAuthnレベル3標準では、パスキーの実装をより多用途でユーザーフレンドリーにするいくつかの新しいクライアント機能が導入されています。getClientCapabilities() API呼び出しの最初のサポートは、Safari 17.4で導入されました。

ブラウザでのサポートを検出するには、以下のスニペットが役立ちます。

// Check if PublicKeyCredential is supported in the current browser
if (typeof PublicKeyCredential === "undefined") {
    console.log("PublicKeyCredential is not supported in this browser.");
}
 
// Check if getClientCapabilities method exists on PublicKeyCredential
if (typeof PublicKeyCredential.getClientCapabilities === "function") {
    try {
        let capabilities = await PublicKeyCredential.getClientCapabilities();
        console.log(capabilities);
    } catch (error) {
        console.error("Error getting client capabilities:", error);
    }
} else {
    console.log("getClientCapabilities is not supported in this browser");
}

getClientCapabilities() を使用すると、ウェブサイトやアプリはクライアント（ブラウザやデバイスなど）に問い合わせて、どのWebAuthn機能をサポートしているかを確認できます。クライアントの機能を理解することで、開発者は生体認証などの利用可能な機能を活用して認証フローを最適化し、特定の機能がない場合は代替手段を提供できます。

Subscribe to our Passkeys Substack for the latest news.

Subscribe

ここでは、WebAuthnクライアント機能と、それらがパスキー統合にどのように影響するかを詳しく見ていきましょう。

conditionalCreateは、特定の条件に基づいてパスキーを自動的に作成することを可能にします。アプリケーションは、パスワードマネージャーが対応している場合、パスワードの自動入力中にこの機能を使用して自動的にパスキーを作成することができます。この機能は、ユーザーをパスワードからパスキーへ自動的に移行させることで、パスキーの採用とその後の利用を促進するのに役立ちます。

conditionalCreateと同様に、conditionalGetはパスキーログインを自動的にトリガーします。これは、最高のパスキーUXを実現し、ログインをパスワードレスだけでなくユーザー名レス（ユーザーはモーダル/ドロップダウンで選択したパスキーをクリックするだけで認証可能）にする場合に便利です。この機能を使用することで、開発者はパスキー認証が適切な場合にのみ行われるようにし、不要なプロンプトを最小限に抑え、ユーザーエクスペリエンスを向上させることができます。

hybridTransportは、パスキーが異なるデバイス間で利用できるようにし、シームレスなクロスデバイス認証（QRコードとBluetooth経由）を可能にします。例えば、ユーザーはスマートフォンに保存されたパスキーを使用して、デスクトップ上のサービスにログインできます。この機能により、ユーザーはパスキーを手動で転送したり、各デバイスで従来のログイン方法に頼ったりすることなく、安全に認証でき、統一された認証体験が促進されます。

Windows Hello、Face ID、Touch IDのようなプラットフォーム認証器は、デバイスに直接組み込まれており、ユーザーが生体認証やその他のデバイス固有の方法（PINパターンなど）で認証できるようにすることで、より速く、スムーズで、安全なパスキー体験を提供します。

Become part of our Passkeys Community for updates & support.

Join

userVerifyingPlatformAuthenticatorは、パスキー認証に、アクティブな指紋スキャンや顔認証などのユーザー検証が含まれることを保証し、セキュリティ層をさらに強化します。

relatedOrigins機能は、同じ組織が所有する異なるドメイン間（例：amazon.comとamazon.de）でのシームレスな認証を可能にします。例えば、企業が複数のドメインを管理している場合や、異なるサブドメインを持っている場合、ユーザーは一度ログインすれば、各プロパティで再認証することなくすべてのプロパティにアクセスできます。この機能はユーザーエクスペリエンスを効率化し、摩擦を減らし、特に国際的な環境や複数のサービスを持つプラットフォームを持つ企業にとって価値があります。

signalAllAcceptedCredentials(options)メソッドは、特定のユーザーに対するWebAuthnクレデンシャルIDの完全なリストを提供します。WebAuthnリライングパーティは、ユーザーが認証済みの場合、プライバシー漏洩のリスクがないため、signalUnknownCredential()の代わりにこのメソッドを使用すべきです。このメソッドは、現在接続されている認証器で更新されていない可能性のある最近の変更を含む、ユーザーの公開鍵認証情報の包括的な概要を提供します。

例を見てみましょう。ユーザー（userId: A）が、Base64URLエンコードでXとYになるクレデンシャルIDを持つ2つのパスキーを持っているとします。その後、ユーザーはウェブサービス（example.com）のアカウント設定でパスキーXを削除します（公開鍵が削除されます）。ここで、以下のスニペットを実行します。

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "A", // WebAuthn User Handle, Base64URL.
    allAcceptedCredentialIds: ["Y"],
});

上記のコードの実行時に認証器が利用可能であれば、認証器は将来の認証セレモニーからパスキーXを削除または非表示にします。しかし、実行時に認証器が接続されていない可能性があるため、リライングパーティは、例えばサインインのたびにこのコードを定期的に実行することが推奨されます。

allAcceptedCredentialIdsに存在しないパスキーは、削除または非表示にされ、元に戻せない可能性があります。そのため、リライングパーティは有効なWebAuthnクレデンシャルIDがリストから決して削除されないように注意することが重要です。もし有効なクレデンシャルIDが誤って削除された場合、リライングパーティはできるだけ早く別のsignalAllAcceptedCredentials(options)呼び出しにそれを含めてパスキーを「再表示」させるべきです。パスキーが非表示ではなく削除された場合、修正する方法はほとんどありません。

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

signalCurrentUserDetails(options)メソッドは、ユーザーの現在の名前とWebAuthn表示名を通知します。signalCurrentUserDetails(options)が呼び出されると、クライアントはこのアクションを実行するために定義された一連のステップに従います。

例を見てみましょう。WebAuthnユーザーID Aを持つユーザーが、ウェブサイト（example.com）のアカウント設定で名前を更新したとします。その場合、リライングパーティは以下のコードを実行できます。

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "A", // user ID, Base64URL.
    name: "New user name",
    displayName: "New display name",
});

認証器は、ローカルに保存されているパスキーのメタデータを更新します。大きな利点は、将来の条件付きUI/パスキー自動入力リクエストで、条件付きUIの選択/ドロップダウンメニューに更新された名前とWebAuthn表示名が表示されることです。

signalUnknownCredential(options)メソッドは、WebAuthnクレデンシャルIDがWebAuthnリライングパーティによって認識されないこと（例えば、ユーザーによってパスキーが削除された場合など）を通知します。signalAllAcceptedCredentials(options)とは異なり、このメソッドは受け入れられたクレデンシャルIDの完全なリストとWebAuthnユーザーハンドルを提供する必要がないため、認証されていない呼び出し元への潜在的なプライバシー漏洩を防ぎます。

例を見てみましょう。ユーザーがウェブサイト（example.com）のアカウント設定でクレデンシャルID Xを持つパスキーを削除します（公開鍵が削除されます）。しかし、秘密鍵はまだユーザーのデバイスで利用可能です。これは、将来の条件付きUI/パスキー自動入力ログインリクエスト（allowCredentialsリストが空の場合）で、そのパスキーがまだ選択できることを意味します。しかし、公開鍵はすでに削除されているため、ログイン試行は失敗します。そのため、リライングパーティは以下を実行すべきです。

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "X", // credential ID the user just tried, Base64URL
});

認証器は、将来の認証セレモニーからクレデンシャルID Xを持つパスキーを削除または非表示にします。

WebAuthnレベル3標準はまだドラフト段階であるため、これらの新しいクライアント機能の採用はまだ完全には広まっていません。さまざまなブラウザがこれらの機能を徐々に実装していますが、サポート状況は異なります。以下は、上記の主要なブラウザにおける利用可能性の最新の概要です。

レベル3が成熟し、より多くのブラウザがこれらの機能を搭載するにつれて、採用のペースは加速するでしょう。現在、どれくらいのユーザーがgetClientCapabilities()を利用できるかを確認したい場合は、無料のPasskeys Analyzerを使用して実際のデータを確認できます。ブラウザのリリースノートや関連ドキュメントに注意を払い、互換性が進化するにつれて計画を立ててください。

Are your users passkey-ready?

Test Passkey-Readiness

開発者として、これらの新しいWebAuthnクライアント機能の検出が自分にとって何を意味し、アプリでどのように使用すべきか疑問に思うかもしれません。以下に、それらを使用するための推奨事項を示します。

ただし、（2024年11月現在）すべてのブラウザがgetClientCapabilities() API呼び出しをサポートしているわけではないことに注意してください。こちらで利用可能なポリフィルがあり、すべてのブラウザが追いつくまで使用できます。

コードの早い段階でgetClientCapabilities()を使用して、ページ読み込み/認証フローの開始時にクライアントがサポートする機能を検出します。これにより、エクスペリエンスを動的にカスタマイズし、デバイス/ブラウザで機能するパスキー機能を提供できます。例えば、サポートされている場合はプラットフォーム認証を推進したり、サポートされていない場合は代替手段（SMS OTPやハードウェアセキュリティキーなど）を提供したりします。

現在パスワードを使用しているウェブサイト/アプリにパスキーを追加する場合、conditionalCreate機能はパスキー採用の真のブースターとなり得ます。適切なクレデンシャルマネージャー（2024年10月現在、Appleパスワードのみ）を使用したパスワード自動入力中にバックグラウンドでパスキーが自動的に生成され、将来の自動入力で優先されます。

高いパスキー採用率だけでなく、高いパスキーログイン利用率も実現するために、conditionalGetをチェックしてデバイス/ブラウザが条件付きUI/パスキー自動入力を使用できるか確認してみてください。これにより、オペレーティングシステム/ブラウザによって積極的に提案され、パスワードの自動入力よりもさらに少ない労力で済むため、ユーザーに作成したパスキーを使用するように促すことができます。

hybridTransportを利用して、クロスデバイス認証（QRコードとBluetooth経由）を有効にし、ユーザーがデスクトップでサービスにアクセスしている場合でも、スマートフォンからシームレスにログインできるようにします。

WebAuthnクライアント機能は、現在存在するパスキーのギャップを埋めるための重要な一歩です。このブログ記事では、WebAuthnクライアント機能に関する主要な質問に取り組みました。

1. WebAuthnクライアント機能とは何か？ これらの機能がブラウザやプラットフォームに特定の機能のサポートを通知させ、開発者が認証フローをより細かく制御できるようにする方法を説明しました。
2. どのようなWebAuthnクライアント機能が存在するのか？ レベル3標準で導入された新しい機能（getClientCapabilities、conditionalCreate、hybridTransportなど）の概要を提供しました。
3. WebAuthnクライアント機能はパスキーの実装をどのように改善するのか？ これらの機能が統合を効率化し、クロスデバイス利用を向上させ、セキュリティを強化する方法について議論しました。
4. WebAuthnクライアント機能はなぜ開発者にとって重要なのか？ これらの機能は、現代のユーザーの期待に沿ったシームレスで安全な認証体験の作成を支援し、実装をより簡単かつ効果的にします。

新しいWebAuthnレベル3の機能をぜひ探求し、ブラウザ間での採用状況を常に最新の状態に保つことをお勧めします。パスキーを実装し、これらの高度な機能を活用したい場合は、専門的なガイダンスとサポートについて、私たちにご連絡ください。