WebAuthn公開鍵クレデンシャル / User-Agentヒント

WebAuthnとパスキーは力強い勢いで普及が進んでいます。また、技術的な観点からも、WebAuthn標準は急速に進化しています。**WebAuthn公開鍵クレデンシャルヒント（User-agentヒントとも呼ばれます）**は、Web Authentication APIに最近追加された機能で、開発者がアプリケーションにパスキー認証を実装する方法を強化することを目的としています。

この記事では、以下の疑問にお答えします。

• WebAuthn公開鍵クレデンシャルヒントとは何か？
• なぜWebAuthn公開鍵クレデンシャルヒントが必要なのか？
• WebAuthn公開鍵クレデンシャルヒントはどのように機能するのか？
• プロジェクトでWebAuthn公開鍵クレデンシャルヒントを使用する際の制限と推奨ケースは何か？

まずは、この機能が必要とされる背景から見ていきましょう。

現在、パスキーを作成・保存できる場所はさまざまです。

• サードパーティのパスワードマネージャー（例：1Password、Dashlane、Bitwarden、KeePassXC）
• Googleパスワードマネージャー / Chromeプロファイル
• iCloudキーチェーン / Appleパスワード
• Windows Hello
• 別のスマートフォン（iOS、Android）またはタブレット（iPadOS、Android）
• ハードウェアセキュリティキー（例：YubiKey）

ユーザーにとっては、これにより柔軟性と選択の自由がもたらされます。しかし、アプリケーションやシナリオによっては、これらの選択肢の一部を制限する必要があります。例えば、セキュリティ要件の強化のためにハードウェアセキュリティキーのみを許可したい場合などです。

このようなパスキー作成と保存方法に影響を与えるために、以前はauthenticatorAttachmentプロパティを使用していました。

Subscribe to our Passkeys Substack for the latest news.

Subscribe

authenticatorAttachmentを使用すると、Relying Party（証明書利用者）はパスキーを作成できる場所を制限できます。

platformは、WebAuthnを実行しているデバイスに組み込まれた認証器（authenticator）を示します。WebAuthnは、プラットフォーム固有のAPIなど、そのプラットフォームに特有のトランスポートメソッドを使用して通信します。プラットフォーム認証器に紐づけられた公開鍵クレデンシャルは、プラットフォームクレデンシャルと呼ばれます。上記のリストから、以下のクレデンシャルマネージャー/場所がプラットフォームクレデンシャルを保存できます。

• サードパーティのパスワードマネージャー（例：1Password、Dashlane、Bitwarden、KeePassXC）
• Googleパスワードマネージャー / Chromeプロファイル
• iCloudキーチェーン / Appleパスワード
• Windows Hello

Windows 11とChromeの場合：

macOS 15 (Sequoia)とChromeの場合：

「キャンセル」をクリックすると、次のモーダルが表示されます。

macOS 15 (Sequoia)とSafariの場合：

cross-platformは、WebAuthnを実行しているデバイスの外部にある認証器（authenticator）（ローミング認証器）を示します。これは複数のデバイスで使用できるためです。WebAuthnは、BluetoothやNFCなどのクロスプラットフォームのトランスポートプロトコルを使用して通信します。ローミング認証器に関連付けられた公開鍵クレデンシャルは、ローミングクレデンシャルと呼ばれます。上記のリストから、以下のクレデンシャルマネージャー/場所がクロスプラットフォームクレデンシャルを保存できます。

• 別のスマートフォン（iOS、Android）またはタブレット（iPadOS、Android）
• ハードウェアセキュリティキー（例：YubiKey）

Windows 11とChromeの場合：

macOS 15 (Sequoia)とChromeの場合：

macOS 15 (Sequoia)とSafariの場合：

指定なしは、プラットフォーム認証器またはクロスプラットフォーム認証器のいずれかを使用できることを示します。この場合、ユーザーはパスキーをどこに保存するかを選択できます。

Windows 11とChromeの場合：

macOS 15 (Sequoia)とChromeの場合：

macOS 15 (Sequoia)とSafariの場合：

「キャンセル」をクリックすると、次のモーダルが表示されます。

authenticatorAttachmentはかなり以前から使用されてきました。しかし、QRコードやBluetoothを介したクロスデバイス認証のような新しい技術の発展に対しては柔軟性に欠けていました。この場合、パスキーは例えばGoogleパスワードマネージャー（プラットフォームクレデンシャル）に保存されますが、Relying Party側ではcross-platformとしてトリガーされます。それに加え、Relying Partyがログイン（登録ではなく）処理で使用すべきパスキーの種類に影響を与えるには、クレデンシャルのtransports値を変更するしかありませんでした。

そこで登場したのが、WebAuthn公開鍵クレデンシャルヒントです。

Become part of our Passkeys Community for updates & support.

Join

WebAuthn公開鍵クレデンシャルヒントは、Web Authentication API（公式にはWebAuthn Level 3で導入）で導入された新しいパラメータです。これらは、認証プロセス中にユーザーが使用する可能性が高い認証器（authenticator）の種類についてブラウザにガイダンスを提供します。これにより、ブラウザのUIを最も関連性の高いオプションに絞り込み、よりスムーズで直感的なユーザーエクスペリエンスを提供できます。

3種類のヒント

ヒントには3つの種類があります。

1. security-key: ユーザーがハードウェアセキュリティキー（例：YubiKey）を使用することが期待されることを示します。
2. client-device: ユーザーがクライアントデバイスに接続されたプラットフォーム認証器（macOSのTouch ID、iOSのFace ID、WindowsのWindows Helloなど）を使用することを示唆します。
3. hybrid: ユーザーがQRコードとBluetoothを介したクロスデバイス認証のためにスマートフォンやタブレットを使用する可能性があることを示します。

これらのヒントはRelying Partyからの厳密な要件ではなく、ブラウザへのヒントとしてユーザーエクスペリエンスを向上させるためのガイダンスとして機能します。

以下は、authenticatorAttachmentを指定せず、WebAuthn User-agentヒントをsecurity-keyに設定した場合のmacOS Sequoia（Edge + Chrome）およびWindows 10（Chrome）のスクリーンショットです。

ここで、security-keyヒントがWindows 10では、少なくとも直接的には尊重されないという別の制限が見られます。フローは基本的にclient-deviceヒントの場合と同じです。

「キャンセル」をクリックすると、次のモーダルが表示されます。

以下は、authenticatorAttachmentを指定せず、WebAuthn User-agentヒントをclient-deviceに設定した場合のmacOS Sequoia（Edge + Chrome）およびWindows 10（Chrome）のスクリーンショットです。

「キャンセル」をクリックすると、次のモーダルが表示されます。

「キャンセル」をクリックすると、次のモーダルが表示されます。

「キャンセル」をクリックすると、次のモーダルが表示されます。

以下は、authenticatorAttachmentを指定せず、WebAuthn User-agentヒントをhybridに設定した場合のmacOS Sequoia（Edge + Chrome）およびWindows 10（Chrome）のスクリーンショットです。

ヒントの導入により、開発者は優先度の高い順に設定の配列を提供できるようになり、より柔軟性が増しました。

以下のコードスニペットは、ユーザーがハードウェアセキュリティキーを使用して認証する可能性が高いことをブラウザに伝え、UIをそれに合わせて調整します。

古いユーザーエージェントとの互換性のために、このヒントをPublicKeyCredentialCreationOptionsで使用する場合、authenticatorAttachmentをcross-platformに設定する必要があります。

const credential = await navigator.credentials.create({
  publicKey: {
    challenge: /* your challenge here */,
    hints: ['security-key'],
    authenticatorSelection: {
      authenticatorAttachment: 'cross-platform'
    }
  }
});

securityヒントは、ウェブサイト/Relying Partyがハードウェアセキュリティキーのみを許可し、ユーザーをその方向に誘導したい高保証レベルのケースで特に価値があります。

この例では、ヒントはユーザーが現在のデバイスに組み込まれたプラットフォーム認証器を使用する可能性があることを示唆しています。

古いユーザーエージェントとの互換性のために、このヒントをPublicKeyCredentialCreationOptionsで使用する場合、authenticatorAttachmentをplatformに設定する必要があります。

const credential = await navigator.credentials.create({
  publicKey: {
    challenge: /* your challenge here */,
    residentKey: true,
    hints: ['client-device'],
    authenticatorSelection: {
      authenticatorAttachment: 'platform'
    }
  }
});

client-deviceヒントの設定は、ユーザーアカウントに複数のパスキーが関連付けられており、その一部がログイン中のデバイスで利用可能である一方、他は別のデバイスに保存されている場合に有益です。システム（パスキーインテリジェンス）が、ログインしようとしているユーザーが高い確率でローカルのパスキーを利用できると検出した場合、このヒントをPublicKeyCredentialRequestOptionsに設定することで、ユーザーが適切なパスキーを選択するための1クリックを節約できます。

この例では、ヒントはユーザーが認証にスマートフォンや同様のデバイスを使用する可能性があることを示唆しています。

古いユーザーエージェントとの互換性のために、このヒントをPublicKeyCredentialCreationOptionsで使用する場合、authenticatorAttachmentをcross-platformに設定する必要があります。

const credential = await navigator.credentials.create({
  publicKey: {
    challenge: /* your challenge here */,
    residentKey: true,
    hints: ['hybrid'],
    authenticatorSelection: {
      authenticatorAttachment: 'cross-platform'
    }
  }
});

hybridヒントは、ユーザーが複数のキーを持っており、システム（パスキーインテリジェンス）が現在のデバイスにはおそらくローカルのパスキーがないと検出した場合に役立ちます。UXを改善し、1クリックを節約するために、このWebAuthn User-agentヒントを設定し、ユーザーに直接クロスデバイス認証（QRコードとBluetooth経由）を促すことができます。さらに、モバイルファーストのパスキーシステムを構築しようとする場合、このヒントを設定することは非常に理にかなっています。

さまざまなオプションを自分で試してみたい場合は、Passkeys Debuggerをご覧になることをお勧めします。

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

Try for Free

WebAuthn公開鍵クレデンシャルヒントが、authenticatorAttachmentやクレデンシャルトランスポートのような他のWebAuthnパラメータとどのように相互作用するかを理解することが重要です。

まず、これらのヒントは厳密な要件ではないことに注意することが重要です。これらはuser-agent（ブラウザ）を拘束するものではなく、リクエストに関するコンテキスト情報を活用して最適なエクスペリエンスを提供するためのガイダンスとして機能します。つまり、ブラウザはヒントを考慮することを選択できますが、厳密に従う義務はありません。

ヒントは優先度の高い順に配列として提供されます。この順序によって、ブラウザがそれらをどのように優先すべきかが決まります。

• 最初のヒントが優先される: 2つのヒントが矛盾する場合、ブラウザは最初のヒントを優先します。
• 重複するヒント: より具体的なヒントがすべてのブラウザで認識されない可能性がある場合、より広範な互換性のために、後からより具体的でないヒントを含めることができます。
• ヒントの重複: 同じヒントが複数回出現した場合、2回目以降の出現は無視されます。

例：

hints: ['security-key', 'hybrid', 'client-device']

この配列では：

1. ブラウザはまずsecurity-keyを優先します。
2. 適用できない場合、hybridを考慮します。
3. 最後に、client-device（クライアントデバイス上のプラットフォーム認証器）を検討します。

ヒントは、authenticatorAttachmentやクレデンシャルトランスポートに含まれる情報と矛盾する可能性があります。このような場合、ヒントが優先されます。これにより、認証器をplatformまたはcross-platformのいずれかに制限していた以前の厳格なauthenticatorAttachmentの使用法と比較して、より柔軟性が提供されます。

矛盾するパラメータを持つ例：

const credential = await navigator.credentials.create({
  publicKey: {
    challenge: /* your challenge here */,
    hints: ['hybrid'],
    authenticatorSelection: {
      authenticatorAttachment: 'platform' // ヒントと矛盾する
    }
  }
});

この場合：

• ヒント: hybrid認証器を優先することを示唆します。
• authenticatorAttachment: platformを指定しており、通常は認証器をクライアントデバイスに限定します。
• 結果: ブラウザはauthenticatorAttachmentよりもヒントを優先し、hybridオプションに焦点を当てます。

現在、WebAuthn公開鍵クレデンシャルヒントはChrome（バージョン128以降）でのみ利用可能です。現時点では、EdgeとSafariがこの機能の統合を計画していると表明していますが、Firefoxはまだリリース時期を明らかにしていません。

Chromeでは、今のところauthenticatorAttachmentパラメータが引き続き尊重されることを覚えておくことが重要です。これは、今日ではどのヒントが設定されていても、authenticatorAttachmentが決定的な要因であることを意味します。しかし、将来のChromeバージョンでは、公開鍵クレデンシャルヒントが優先され、唯一のアプローチになると予想されます。

最新のChromeバージョンがWebAuthn User-agentヒントをサポートしているにもかかわらず、これらのヒントはWindows 11およびWindows Hello / Windowsセキュリティでは尊重されません。その根本的な理由は、UIがオペレーティングシステム（Windows Hello / Windowsセキュリティ）自体によって制御されているためです。

さらに、Googleパスワードマネージャーに保存され、Windows 11に同期されたパスキーの場合、WebAuthn User-agentヒントは尊重されません。これは、Windows 11での最終的なローカル認証がWindows Hello / Windowsセキュリティで行われるためです。今後のWindows 11でのMicrosoftアカウントを介したパスキーの同期により、Windows 11とWebAuthn User-agentヒントに関しても改善が期待されます。

一方、Windows 10では、WebAuthn User-agentヒントは尊重されます。これは、WebAuthnのUIがWindows Hello / Windowsセキュリティではなく、Chromeによって処理されるためです。しかし、私たちのテストでは、security-keyの効果は見られませんでした。このヒントが設定された場合、フローはclient-deviceのものと似ていました。

WebAuthn公開鍵クレデンシャル（user-agent）ヒントは、開発者とユーザーの両方にさまざまなメリットをもたらします。この機能はまだ新しく、すべてのブラウザやオペレーティングシステムに展開されているわけではありません（2024年10月現在）。

特にWindows 11に伴う現在の制限を認識することが重要です。Windows 11では、パスキーのUIはWindows Hello（Windows Helloセキュリティモーダル）によって処理され、これが現在、Chrome / EdgeのWebAuthn User-agentヒントのサポートよりも優先されます。これは、GoogleパスワードマネージャーからWindowsに同期されるパスキーにも当てはまります（この場合も、ヒントはまだ効果がありません）。

これは、WebAuthn公開鍵クレデンシャルヒントが、主要なデスクトップオペレーティングシステムの中では、macOSとWindows 10でのみ実際に機能することを意味します。

さらに、2024年10月現在、これらのオペレーティングシステムでChrome / Edgeが使用されている場合でも、authenticatorAttachmentが設定されていると、これもWebAuthn User-agentヒントよりも優先されます（Googleが述べているように）。

ユースケースの観点から、この新機能から最大限の価値を引き出すために、以下の推奨ユースケースが考えられます。

バックエンドとパスキーインテリジェンスを構築する際には、公開鍵クレデンシャルヒントを適切に使用してログインを容易にし、ユーザーの不要なクリックを省くようにしてください。例えば、システムがユーザーがローカルのパスキーを利用できる可能性が高いデバイスでログインしていることを検出した場合、client-deviceヒントを使用します。

ユーザーが新しいデバイスからウェブサイトにアクセスし、パスキーインテリジェンスがユーザーのモバイルデバイスにパスキーが存在する可能性があることを知っている場合は、ヒントをhybridに設定し、ユーザーが素早くQRコードをスキャンしてハイブリッドパスキーを利用できるようにします。

ここでの主な目標は、よりシームレスで直感的なユーザーエクスペリエンスを提供することです。どの認証器が使用される可能性が高いかをブラウザに案内することで、開発者はログインプロセス中のユーザーの混乱や摩擦を減らすことができます。ユーザーが不要な認証オプションに圧倒される代わりに、ヒントによってブラウザは最も関連性の高い選択肢に集中でき、より速く、より簡単なエクスペリエンスにつながります。

ユーザー認証のためにハードウェアセキュリティキーを標準化している高保証レベルの企業や政府機関は、パスキークレデンシャルヒントが特に有用であると感じるでしょう。security-keyヒントを使用することで、ブラウザがハードウェアセキュリティキーのオプションを目立つように表示することを保証できます。

これは、従業員にハードウェアセキュリティキーが支給されており、他の認証方法（プラットフォーム認証器など）が許可されていない大規模な組織で特に役立ちます。security-keyヒントにより、企業は将来の改善のための柔軟性を制限することなく、認証フローを固定化できます。

hybridヒントは、クロスデバイス認証、ひいてはモバイルファーストのアプローチが望まれるシナリオや、ユーザーが頻繁にデバイスやプラットフォーム間を移動する場合に真価を発揮します。

このユースケースの例としては、ほとんどのユーザーが生体認証またはウェブベースの認証アプリ（モバイルファーストパスキー）を介してスマートフォンで認証することを想定している消費者向けアプリが挙げられます。hybridをヒントとして指定することで、開発者はブラウザのUIがスマートフォンの使用を促し、利便性とアクセシビリティを向上させることを保証します。

WebAuthn公開鍵クレデンシャルヒントは、パスキー認証中のユーザーエクスペリエンスを向上させるための柔軟な方法を提供します。私たちが得た知見をもとに、冒頭の質問を再確認してみましょう。

1. WebAuthn公開鍵クレデンシャルヒントとは何か？

   これらは、ウェブサイト/アプリがクライアントに提供する任意の提案であり、ユーザーが使用する可能性が最も高い認証方法（ハードウェアセキュリティキー、プラットフォーム認証器、またはクロスデバイス認証のようなハイブリッドソリューション）を案内します。

2. なぜWebAuthn公開鍵クレデンシャルヒントが必要なのか？

   ユーザーに提示されるオプションを絞り込むことで認証プロセスを合理化し、不要な摩擦やクリックを減らし、全体的なエクスペリエンスを向上させます。

3. WebAuthn公開鍵クレデンシャルヒントはどのように機能するのか？

   開発者はコンテキストに基づいてsecurity-key、client-device、hybridなどのヒントを指定し、ブラウザがユーザーにとって関連性の高い認証方法を優先できるようにします。これらのヒントは厳密な要件ではありませんが、認証中のUIフローを最適化するのに役立ちます。

4. 制限と推奨ユースケースは何か？

   現在、これらのヒントの完全なサポートはChromeとEdgeに限定されており、Windows 11などの他のブラウザやオペレーティングシステムでは互換性のレベルが異なります。最も効果的なユースケースには、ログインUXの改善、高セキュリティ環境でのハードウェアセキュリティキー使用の強制、モバイルファーストアプリケーションでのクロスデバイス認証の有効化などがあります。

結論として、WebAuthn公開鍵クレデンシャルヒントにより、開発者は各ユーザーシナリオに最も適したオプションにブラウザを誘導することで、より直感的でユーザーフレンドリーな認証プロセスを作成できます。まだ進化の途上にあるものの、この機能はパスキー実装におけるセキュリティとユーザーエクスペリエンスの両方を大幅に向上させることができます。