userVerification の詳細

Eiji Kitamura

このドキュメントでは、WebAuthn における userVerification の内容と、パスキーの作成時または認証時に userVerification を指定した場合のブラウザの動作について説明します。

「ユーザー確認」とはどうでしょうか

パスキーは公開鍵暗号で構築されます。パスキーを作成すると、公開鍵 / 秘密鍵のペアが生成されます。秘密鍵はパスキー プロバイダによって保存されます。公開鍵はリライング パーティ（RP）サーバーに返されて保存されます。サーバーは、ペア設定された公開鍵を使用して、同じパスキーで署名された署名を検証することでユーザーを認証できます。「ユーザー提示」公開鍵認証情報上の（UP）フラグは、認証中に誰かがデバイスを操作したことを証明するものです。

ユーザー確認はオプションのセキュリティ レイヤで、ユーザー プレゼンス アサートのように、認証時に特定の人物だけでなく正しい人物も存在したことをアサートしようとします。スマートフォンでは、生体認証、PIN、パスワードなど、画面ロックのメカニズムを使用するのが一般的です。ユーザー確認が行われたかどうかは「UV」でレポートされます。パスキーの登録と認証中に認証システムのデータで返されるフラグ

</ph> <ph type="x-smartling-placeholder">で確認できます。

</ph> <ph type="x-smartling-placeholder">

サーバーでの UP と UV の検証方法

ユーザー プレゼンス（UP）とユーザー検証（UV）のブール値フラグは、サーバーの認証システムのデータ フィールドでサーバーに送信されます。認証中、認証システムのデータ フィールドの内容は、保存されている公開鍵を使用して署名を検証することで検証できます。署名が有効である限り、サーバーはフラグが本物であるとみなすことができます。

</ph> <ph type="x-smartling-placeholder">

パスキーの登録と認証時に、サーバーは UP フラグが true であることと、要件に応じて UV フラグが true か false かを確認する必要があります。

userVerification パラメータの指定

WebAuthn の仕様では、RP は、認証情報の作成とアサーションの両方で userVerification パラメータを使用してユーザー確認をリクエストできます。これは、それぞれ次の意味の 'preferred'、'required'、'discouraged' を受け入れます。

• 'preferred'（デフォルト）: デバイスでユーザー確認方法を使用することが推奨されますが、使用できない場合はスキップできます。レスポンス認証情報には、ユーザー確認が実行された場合の UV フラグ値 true と、UV が実行されていない場合は false が含まれます。
• 'required': デバイスで利用可能なユーザー確認メソッドを呼び出す必要があります。利用できない場合、リクエストはローカルで失敗します。つまり、レスポンス認証情報は常に UV フラグが true に設定された状態で返されます。
• 'discouraged': ユーザー確認方法を使用することはおすすめしません。ただし、デバイスによってはユーザー確認が実行される場合があり、UV フラグに true または false を含めることができます。

パスキー作成のサンプルコード:

const publicKeyCredentialCreationOptions = {
  // ...
  authenticatorSelection: {
    authenticatorAttachment: 'platform',
    residentKey: 'required',
    requireResidentKey: true,
    userVerification: 'preferred'
  }
};

const credential = await navigator.credentials.create({
  publicKey: publicKeyCredentialCreationOptions
});

パスキー認証のサンプルコード:

const publicKeyCredentialRequestOptions = {
  challenge: /* Omitted challenge data... */,
  rpId: 'example.com',
  userVerification: 'preferred'
};

const credential = await navigator.credentials.get({
  publicKey: publicKeyCredentialRequestOptions
});

userVerification にはどのオプションが適していますか。

使用する userVerification 値は、アプリの要件とユーザー エクスペリエンスのニーズによって異なります。

userVerification='preferred' を使用するタイミング

保護よりもユーザー エクスペリエンスを優先する場合は、userVerification='preferred' を使用します。

ユーザーの確認は、保護よりも摩擦が激しい環境があります。たとえば、Touch ID が使用できない macOS の場合（デバイスが対応していない、無効になっている、デバイスがクラムシェル モードになっているなど）、ユーザーはシステム パスワードを入力するよう求められます。これが煩わしさを感じ、ユーザーは認証を完全に断念する可能性があります。手間を省くことがより重要な場合は、userVerification='preferred' を使用してください。

</ph> <ph type="x-smartling-placeholder">

userVerification='preferred' では、ユーザー確認が正常に行われた場合、UV フラグは true になり、ユーザー確認がスキップされた場合は false になります。たとえば、Touch ID を使用できない macOS では、ユーザー確認をスキップするボタンをクリックするようユーザーに求め、公開鍵認証情報には false UV フラグが含まれています。

UV フラグは、リスク分析のシグナルとして使用できます。他の要因が原因でログインにリスクがあると思われる場合は、ユーザーの確認が行われていない場合は、ユーザーに追加のログイン時の本人確認画面を表示することをおすすめします。

userVerification='required' を使用するタイミング

UP と UV の両方が必要だと思われる場合は、userVerification='required' を使用します。

このオプションの欠点は、ユーザーがログインするときに、より多くの煩わしさを感じる可能性があることです。たとえば、Touch ID を使用できない macOS の場合、ユーザーはシステム パスワードを入力するよう求められます。

userVerification='required' を使用すると、ユーザー確認がデバイスで実行されるようにできます。UV フラグが true であることをサーバーが確認していることを確認します。

まとめ

ユーザー確認を活用することで、パスキーを利用する当事者は、デバイス所有者がログインする可能性を測定できます。代替のログイン メカニズムがユーザーフローに与える影響の度合いに応じて、ユーザー確認を要求するかオプションにするかは、ユーザーが選択します。パスキーのユーザー認証の UP フラグと UV フラグをサーバーがチェックすることを確認します。