多要素認証チュートリアル

  1. 多要素認証とは？
  2. User Verificationとは？
  3. デモ
    1. 登録
    2. 認証
  4. パラメータ説明

多要素認証とは？

多要素認証（MFA）は、認証仕組みに２つ以上のエビデンス、またはよ要素を正常に提示した後のみ、コンピューターユーザーにアクセスを許可する認証方法です。
要素は次のとおりです。

  • Something you knows（知識情報）：パスワード、PINコード等
  • Something you have（所持情報）：セキュリティーキー、スマートカード等
  • Something you are（生体情報）：バイオメトリクス

User Verificationとは？

２要素認証チュートリアルのシナリオは、MFAの例です。しかし、 パスワードレス認証 チュートリアルのようにパスワードを削除し、 ユーザー名なしで認証 チュートリアルのようにユーザー名も削除する場合、MFAではなく、完全に安全ではありません。 攻撃者は、ユーザー名を知っていて、セキュリティーキーを持っている場合、アカウントにアクセスできます。

FIDO2プロトコルを使用すると、認証器は様々な認証ジェスチャーによってユーザーを確認できます。 例えば、タッチ＋PINコード、パスワード入力、またはバイオメトリクス（指紋認証等）を使用します。このプロセスは User Verification （UV）と呼ばれます。 userVerification パラメータは、以下の３つの値があります。

  • required: Relying Party（RP）は、操作のためにユーザー確認（user verification）が必要です。
  • preferred: RPは、可能であれば、操作のためにユーザー確認が必要です。
  • discouraged: RPは、操作中にユーザー確認を行いません。

UVを強制するには、 新しいクレデンシャルを登録する時、及び登録したクレデンシャルを認証する時、 userVerification パラメータは required である必要があります。

注意

  • 認証器は、利用可能なメソッド（生体認証、clientPINなど）のいずれかを使用してUVを実行します。
  • 認証器はUVをサポートしない場合があります。UVを実行できない場合、詳細については、認証器ベンダーにお問い合わせください。
  • 認証器は既にclientPINを設定された場合、userVerification = discouragedでもUVが要求されます。

デモ

パスワードレス認証 のシナリオは再利用されます。 userVerification パラメータのみ変更があります。

1. 登録

このデモサイトには既にアカウント・クレデンシャルを登録しました？認証へ進む！
  • 1

    ユーザー情報入力

    ユーザーを識別するための特定のユーザー名、またはメールアドレス。
    表示のみを目的とした、わかりやすい名前。

2. 認証

まだ登録していません？登録に戻ってください！
  • 1

    ユーザー名入力

    サーバーから登録したクレデンシャルIDのリストを取得するため、ユーザー名が必要です。 次に、認証器は適切なクレデンシャルを選択し、認証サーバーに送信します。

    登録したユーザー名

パラメータ説明

以下はクレデンシャルの登録の時に使用するパラメータです。 


<script>
    // 可能の値：none (デフォルト), direct, indirect
    let attestation = "none"; // Replying Party (RP)は、認証器の証明が必要がないこと

    let authenticatorSelection = {
        // 可能の値：<empty> (デフォルト), platform, cross-platform
        'authenticatorAttachment': "", // RPは認証器のタイプを指定しないこと。ユーザーは使用したい認証器を選択できます。
        // 可能の値：preferred, required, discouraged (デフォルト)
        'userVerification': "required", // RPは、操作のためにユーザー確認（user verification）が必要です。
        // 可能の値：true, false (デフォルト)
        'requireResidentKey': false // 公開鍵クレデンシャルを生成した時、認証器はクライアント側に常駐する公開鍵クレデンシャルソースを生成する必要がないこと
    };
</script>

RPは、クレデンシャルの生成中に認証器の検証に関する優先度を指定できます。Attestationパラメータは、以下の３つの値があります。

  • none: RPは認証器の証明が必要がないこと。
  • indirect: RPは認証器の検証を優先しますが、クライアントは、検証で使うステートメントを取得する方法を決定できます。
  • direct: RPは、認証器が生成した検証ステートメントを受信したいこと。

このデモでは、デファクト値が使用されています。RPサーバーは高いセキュリティーが必要な場合は、 "direct"を使用して、クライアントに完全なステートメントを強制的に返させる必要があります。
UserVerificationパラメータは User Verificationとは？で説明しました。
また、RequireResidentKeyの使い方は ユーザー名なしの認証で説明します。

以下はクレデンシャルの認証の時に使用するパラメータです。 


<script>
    // 可能の値：preferred, required, discouraged (デフォルト)
    'userVerification': "required", // RPは、操作のためにユーザー確認（user verification）が必要です。
</script>

RPはこれらのパラメータを指定しない場合、FIDO2認証サーバーはデファクト値と設定します。