MFAフローとは？多要素認証のUI設計・登録・ログイン・復旧まで徹底解説

MFAは「Multi-Factor Authentication」の略で、日本語では多要素認証と呼ばれます。利用者がアカウントへアクセスするとき、パスワードだけに依存するのではなく、異なる種類の認証要素を組み合わせて本人であることを確認する方法です。例えば、利用者が知っているパスワードと、利用者が所有しているスマートフォン上の認証アプリを組み合わせれば、一つの認証情報が盗まれただけではログインが成立しにくくなります。しかし、MFAの品質は「第二要素を追加したか」という一点だけでは決まりません。登録、ログイン、認証失敗、端末紛失、再認証、認証要素変更といった一連のフローを安全に設計する必要があります。

UIデザインの観点でも、MFAは単純な入力フォームではありません。「コードはどこへ送信されたのか」「何分間有効なのか」「コードが届かなければどうするのか」「スマートフォンが使えない場合はどうするのか」「別の認証方法へ切り替えられるのか」「現在の操作が本当に自分のログイン要求なのか」といった不安や判断が連続します。安全性を優先して説明不足の複雑な画面を作れば正規利用者がログインできなくなり、操作性を優先して簡単な迂回経路を作れば、その迂回経路が攻撃者によるアカウント乗っ取りの入口になる可能性があります。

2025年8月に公開された現在のNIST SP 800-63Bでは、認証保証レベル2では二つの異なる認証要素の所有・制御を証明することが求められ、フィッシング耐性を持つ認証方式を選択肢として提供することも要求されています。より高い認証保証レベル3では、フィッシング耐性を備え、秘密鍵を持ち出せない暗号学的認証器が必要になります。つまり、現代のMFA設計では「SMSか認証アプリを付ければ終わり」ではなく、攻撃耐性、利用者環境、復旧方法まで含めて方式を選択する必要があります。

1. MFAフローとは

MFAフローとは、複数の異なる認証要素を利用して、アカウントへアクセスしようとしている人物が正規利用者であることを段階的に確認する一連の処理と画面遷移を指します。ログイン画面だけではなく、認証器の登録、認証方式の選択、チャレンジの発行、検証、エラー処理、セッション確立までを含めて設計することが重要です。

1.1 MFAで使用する認証要素

MFAでは、一般的に「利用者が知っているもの」「利用者が持っているもの」「利用者自身の特徴」といった異なる種類の証拠を組み合わせます。パスワードや暗証番号は知識要素、スマートフォンやセキュリティキーは所有要素、指紋や顔などの生体情報は本人特性に基づく要素として扱われます。同じ種類の要素を二つ要求しても、多要素認証として同等の安全性が得られるとは限りません。

例えばパスワードに加えて別の暗証番号を入力させても、どちらも「知っているもの」という同じ種類の要素であり、一つのフィッシング画面で同時に取得される可能性があります。一方、パスワードと物理的なセキュリティキーを組み合わせれば、遠隔攻撃者は二種類の証拠を取得する必要があります。OWASPも、MFAでは独立した要素を組み合わせ、同じ攻撃によって同時に突破されにくくすることを重要な考え方として説明しています。

1.2 MFAフローに含まれる段階

MFAフローは、通常、利用者識別、第一認証、第二認証、認証結果、セッション開始という複数の段階で構成されます。例えばメールアドレスとパスワードを入力し、それらが正しければ認証アプリのコード入力画面へ移動し、コードが検証された後にアプリケーションへアクセスできるようになります。パスキーを使う場合は、一つの認証器の中で所有要素と端末上の暗証番号や生体確認を組み合わせることもあります。

しかし実際の製品では、正常系だけではフローは完成しません。認証コードが届かない、コードの有効期限が切れる、端末を紛失する、認証アプリを削除する、別の端末からログインする、認証要素を変更するといった状況が必ず発生します。したがって、MFAフローを設計する際には、正常にログインできる最短経路だけでなく、利用者が問題から安全に回復する経路を同時に設計する必要があります。

1.3 認証チャレンジと検証

第二要素が必要になると、サーバーは利用者へ認証チャレンジを提示します。認証アプリ型であれば現在の一時パスワードを入力させ、プッシュ型であれば登録済み端末へ承認要求を送り、パスキーではブラウザーや端末を通して暗号学的なチャレンジへの署名を求めます。利用者が提示した証拠をサーバー側で検証し、正しい場合にのみ認証処理を進めます。

この段階では、認証チャレンジを単に表示するだけでなく、どの操作に対する確認なのかを利用者が理解できることが重要です。「承認してください」とだけ表示すると、不正ログインによって送信された要求まで誤って承認する可能性があります。ログイン先、端末、時刻、必要に応じて概略的な位置などを伝え、自分が開始した操作であるか判断できる情報を提供します。

1.4 認証成功後にセッションを確立する

すべての必要な要素が検証されたら、サービスは認証済みセッションを確立します。この時点で初めて利用者は保護された機能へアクセスできます。第一要素だけを検証した途中状態を、通常のログイン済み状態として扱わないことが重要です。第二要素検証前のセッションには限定された目的だけを許可し、本来の利用者データへアクセスできないようにします。

また、認証が一度成功したからといって無期限に同じ保証を維持できるわけではありません。長期間操作がない場合や、パスワード変更、認証要素変更、金融取引などの高リスク操作を実行する場合には再認証が必要になります。MFAフローはログイン成功画面で終了するのではなく、セッションの寿命まで含めて設計する必要があります。

1.5 MFAを画面単位ではなくフロー単位で設計する

UI制作でよく起きる問題は、「MFAコード入力画面」だけを単独コンポーネントとして作り、その前後の状態を実装担当者へ任せることです。しかし、利用者が最も困るのは入力欄の見た目ではなく、「届かない」「使えない」「端末を失った」「何度入力しても失敗する」といった状態です。MFAでは例外経路の品質が、実際のログイン成功率や問い合わせ件数へ大きく影響します。

デザイナーはログイン開始からセッション確立までを一枚のフローとして描き、各段階からどの例外へ移動できるかを定義します。認証方式を変更した場合に第一要素を再入力するのか、失敗回数が一定値を超えた場合に何を表示するのか、復旧フローから戻った際に元の操作を再開できるかなど、画面間の状態を明確にすることが必要です。

2. MFAと二要素認証の違い

MFAと二要素認証は同じ意味として使われることがありますが、厳密には範囲が異なります。二要素認証は二種類の認証要素を要求する方式であり、多要素認証は二つ以上の異なる認証要素を利用する、より広い概念です。

2.1 要求する認証要素数の違い

二要素認証では、その名前のとおり二種類の認証要素を組み合わせます。例えばパスワードと認証アプリ、パスワードとセキュリティキーなどです。一般的な消費者向けサービスで「MFAを有効にする」と表示されている機能も、実際には二種類の要素による二要素認証であることが多くあります。

MFAは二要素認証を含む上位の考え方であり、必要な保証レベルによって三種類以上の証拠を要求することも理論上可能です。ただし、認証要素を増やせば無条件に安全になるわけではなく、操作負担や復旧リスクも増えるため、サービスのリスクに応じて必要な強度を設計します。

2.2 二段階認証との違い

「二段階認証」という言葉は、処理が二つの段階に分かれていることを表す場合があります。しかし、二段階であっても両方が同じ種類の認証要素であれば、厳密な意味で二要素認証とは限りません。例えば二つの異なる秘密情報を順番に入力するだけでは、両方とも知識要素になる可能性があります。

UI上では二つの画面が表示されるため、利用者から見ると二要素認証と同じように感じられますが、安全性を評価するときは画面数ではなく、独立した要素が何種類存在するかを確認する必要があります。デザイナーも「二画面に分けたからMFAになっている」と考えず、認証基盤担当者と方式を確認します。

2.3 パスワードと暗証番号との違い

パスワードの後に四桁の暗証番号を要求すると、利用者は二回秘密情報を入力するため、安全性が大きく向上したように感じるかもしれません。しかし両方とも利用者が記憶している秘密であれば、基本的には同じ知識要素へ依存しています。フィッシングサイトが両方を要求すれば、一度に取得される可能性があります。

対して、パスワードと登録済み物理端末を組み合わせる場合、攻撃者はパスワードだけでなく端末やその暗号鍵を制御する必要があります。MFAを設計するときは、入力回数の多さよりも、攻撃者が同時に突破しにくい種類の異なる要素を組み合わせているかを重視します。

2.4 MFAとパスワードレス認証の違い

MFAだから必ずパスワードを使用するわけではありません。パスキーのような方式では、利用者が端末を所有していることと、端末内の暗証番号や生体認証によって認証器を利用できることを組み合わせ、一つの認証操作で複数要素を満たせる場合があります。NISTも、多要素暗号学的認証器では所有要素と、それを有効化する知識要素または本人特性を組み合わせる考え方を示しています。

そのため、UIで「MFA＝パスワード入力後にコード入力」という固定的なモデルを前提にすると、パスキーなどの新しい認証方式へ対応しにくくなります。認証画面は特定の入力欄を中心に設計するのではなく、「利用可能な認証方法を提示し、必要な保証を満たす」という考え方で設計した方が長期的に拡張しやすくなります。

2.5 安全性は「要素数」だけでは決まらない

MFAを評価するときに、「二要素だから安全」「三要素だからもっと安全」という数字だけの比較は適切ではありません。SMSによるコードとフィッシング耐性のあるセキュリティキーでは、同じ所有要素でも攻撃に対する性質が大きく異なります。また、復旧手続きがメール一通だけでMFAを解除できるなら、通常のログインが強固でも復旧経路が弱点になります。

NIST SP 800-63Bでは、認証保証レベル2でフィッシング耐性のある認証方法を選択肢として提供することが要求され、レベル3ではフィッシング耐性を持つ暗号学的認証器が必須です。現代のMFA設計では、要素の個数に加えてフィッシング、リプレイ、要素紛失、復旧攻撃など、想定する脅威への耐性を確認する必要があります。

3. MFA方式を選択する

MFAのUIフローを設計する前に、どの認証方式を提供するかを決める必要があります。ワンタイムパスワード、SMS、プッシュ通知、セキュリティキー、パスキーなどでは、安全性だけでなく必要端末、通信環境、復旧方法、アクセシビリティが異なります。

3.1 認証アプリによる一時パスワード

時間ベースの一時パスワードでは、利用者が認証アプリに表示された数字をサービスへ入力します。特別な通信がなくてもコードを生成できるため、携帯回線が利用できない場所でも使用でき、広く利用されてきました。サービス側では、登録時に共有した秘密情報と時刻から同じコードを計算して検証します。

一方で、利用者が数字を手作業でWebサイトへ入力する方式であるため、偽サイトが同じコードを要求し、本物のサービスへ即時転送するリアルタイム型フィッシングには弱いという性質があります。NISTも、利用者が認証器出力を手入力する一時パスワード方式をフィッシング耐性がある方式とは認めていません。

3.2 SMSによる認証コード

SMS認証は利用者が追加アプリを導入しなくても利用しやすく、電話番号を登録しているサービスでは導入の障壁を下げられます。利用者はメッセージで届いた一時コードを入力するため、認証アプリを知らない人にも理解されやすい方式です。

しかし、SIM交換を悪用した攻撃、電話番号の再割り当て、通信経路への依存、ロック画面へのコード表示など複数の弱点があります。高リスクサービスではより強力な方式を優先し、SMSを提供する場合も、他の方式を利用できない場合の補助経路として位置付けるなど、リスクに応じた設計が必要です。OWASPもSMSや電話による方式には複数のリスクがあることを示しています。

3.3 プッシュ承認

プッシュ承認では、登録済みスマートフォンへログイン要求を送り、利用者が端末上で承認または拒否します。数字を転記する必要がないため操作負担を減らせますが、単純な「承認」ボタンだけでは、攻撃者が繰り返し通知を送り、利用者が誤って承認するMFA疲労攻撃へつながる可能性があります。

安全性を高めるためには、ログイン画面に表示された番号とスマートフォン側の番号を一致させる方式や、要求元の情報を表示する方法を検討します。利用者が自分の操作であることを確認してから承認できるフローを作り、突然届いた要求については明確に拒否できるようにします。

3.4 セキュリティキー

物理的なセキュリティキーは、USB、NFCなどを通じて端末へ接続し、公開鍵暗号を利用して認証を行います。認証情報をWebサイトへ数字として入力しないため、適切な方式ではフィッシングへの強い耐性を持たせることができます。

一方、利用者がキーを持ち歩く必要があり、紛失、故障、端末との接続方式の違いを考慮する必要があります。重要アカウントでは複数のキーを登録できるようにし、一つを予備として安全な場所へ保管できる設計が有効です。

3.5 パスキー

パスキーは公開鍵暗号を用いた認証方式で、利用者がサイトへ共有秘密を入力する代わりに、端末側の認証器がサービス固有のチャレンジへ応答します。端末内の暗証番号、指紋、顔などで認証器を有効化するため、一つの自然な操作の中で強力な本人確認を実現できます。

OWASPはパスキーについて、所有要素と知識または本人特性を組み合わせられ、フィッシングへの耐性を持つ有力な認証方式として扱っています。NISTの現行ガイドラインも同期可能な認証器を正式に扱っており、MFAフローを新規設計する際には、従来型コード入力だけでなくパスキーを主要選択肢として検討する価値があります。

4. MFA初回登録フロー

MFAはログイン時だけでなく、最初に認証要素をアカウントへ関連付ける登録工程が非常に重要です。登録中に攻撃者の認証器を追加できてしまえば、その後どれほど強力な認証方式を採用していても意味がありません。

4.1 MFAを設定する理由を最初に説明する

MFA登録画面へ突然QRコードや入力欄を表示すると、利用者はなぜ追加作業を求められているのか理解できない場合があります。特に任意設定の場合は、設定によって何が守られるのか、どの程度の時間が必要なのか、スマートフォンなど何を準備すればよいのかを最初に説明します。

説明はセキュリティ用語を並べるのではなく、「パスワードが他人に知られた場合でも、追加の確認によってアカウントへの不正アクセスを防ぎやすくします」のように利用者の利益として書きます。設定途中で別アプリのインストールが必要になる場合は、開始前に知らせることで途中離脱を減らせます。

4.2 利用可能な方式を選択させる

複数方式を提供する場合は、「認証アプリ」「パスキー」「セキュリティキー」などを利用者が比較できる画面を用意します。単に方式名だけを表示すると、一般利用者には違いが分からないため、必要なもの、操作方法、安全性、オフライン利用可否などを簡潔に説明します。

最も推奨する方式がある場合は、画面上で明確に示します。ただし「おすすめ」という表示だけではなく、「フィッシングに強く、コード入力が不要」のように理由を伝える方が選択しやすくなります。古い方式をデフォルトの最上部へ残し続けると、より安全な方法へ移行しにくくなります。

4.3 認証器をアカウントへ関連付ける

認証アプリではQRコードを読み取って共有秘密を登録し、パスキーではブラウザーの認証APIを通じて新しい資格情報を生成し、公開鍵をアカウントへ登録します。この段階では、QRコードを表示しただけ、新しい鍵を生成しただけで登録完了と判断してはいけません。

実際に利用者がその認証器を制御していることを確認するため、一時パスワードを一度入力してもらう、生成したパスキーで確認を行うなどの検証を挟みます。設定画面を閉じる前に正常な認証が一度成立することを確認すれば、誤登録による即時ロックアウトを減らせます。

認証アプリ登録画面のHTML例

<section aria-labelledby="mfa-setup-title">  <h2 id="mfa-setup-title">認証アプリを設定</h2>  <p>    認証アプリでQRコードを読み取り、    表示された6桁の確認コードを入力してください。  </p>  <img    src="/mfa/qr"    alt="認証アプリ登録用QRコード"  >  <label for="verification-code">    6桁の確認コード  </label>  <input    id="verification-code"    name="verification-code"    inputmode="numeric"    autocomplete="one-time-code"  >  <button type="submit">    設定を確認  </button> </section>

4.4 復旧手段を同時に用意する

MFAを設定した直後に、端末紛失時の復旧方法も設定します。予備の認証器、回復コード、別のセキュリティキーなどを用意しないと、端末を一台失っただけで正規利用者が完全にロックアウトされる可能性があります。

回復コードを提供する場合は、「後で確認できます」と簡単に閉じられる画面にせず、保存方法と使用目的を説明します。ただし復旧情報そのものが新しい秘密になるため、安全な保管を求め、画面共有や共用端末上で不用意に露出させない配慮も必要です。

4.5 設定完了状態を明確にする

登録が成功したら、「設定しました」とだけ表示するのではなく、登録された方式と認証器名を確認できるようにします。「このiPhone」「会社用セキュリティキー」のような名称を設定できれば、後で不要な認証器を削除するときにも判断しやすくなります。

さらに、次回ログイン時にどのような操作が必要になるかを簡単に説明します。利用者が登録した直後にログアウトし、再ログインで初めて見慣れない認証画面へ遭遇するより、設定完了画面で次の体験を予告した方が安心して利用できます。

5. MFAログインフロー

通常のMFAログインでは、利用者識別と第一要素の検証後に追加認証を要求します。しかし、画面遷移の順序、エラー表示、別方式への変更などを適切に設計しなければ、正規利用者にとって毎回大きな負担になります。

5.1 利用者を識別する

最初にメールアドレス、利用者名などを入力してアカウントを識別します。この段階で登録済み認証方式を判断し、必要な次画面を構成できるようになります。ただし、アカウントの存在有無を攻撃者へ簡単に推測させないよう、エラー表示やAPI応答にも配慮する必要があります。

UIとしては、利用者が自分のアカウントを正しく選べているか確認できることが重要です。複数アカウントを利用する環境では、第二要素画面にも対象メールアドレスなどを安全な範囲で表示し、別アカウントの認証コードを入力して混乱することを防ぎます。

5.2 第一要素を検証する

パスワードを使用する構成では、第一要素としてパスワードを検証します。パスワードが不正な場合には第二要素を送信しない設計が一般的であり、不要なSMS送信やプッシュ通知を防ぎます。

一方で、エラー表示からアカウントの存在や第一要素の正否を攻撃者へ必要以上に知らせないようにする必要があります。利用者が自分で修正できる分かりやすさと、認証情報の推測を助けない安全性のバランスを取ります。

5.3 第二要素を要求する

第一要素が正しい場合、登録済みMFA方式に応じて第二要素を要求します。認証アプリであればコード入力、プッシュであれば承認待ち、セキュリティキーなら挿入や接触、パスキーなら端末の認証UIが起動します。

ここでは「確認してください」だけではなく、何をすればよいかを明確にします。「認証アプリを開き、現在表示されている6桁のコードを入力してください」「スマートフォンに送信したログイン要求を確認してください」のように、次の行動を一文で理解できるようにします。

5.4 認証成功後に元の目的へ戻す

ログイン途中で利用者が特定のページへアクセスしようとしていた場合、MFA成功後にホーム画面へ戻してしまうと目的の操作をやり直さなければなりません。認証前の安全な遷移先情報を保持し、成功後に元の目的へ戻せるようにします。

ただし、外部から与えられた任意URLへそのまま転送する実装は、別のセキュリティ問題を生む可能性があります。許可されたアプリケーション内部の遷移先だけを使用し、認証状態と遷移処理を安全に管理します。

5.5 別方式への切り替えを提供する

登録している認証方式が複数ある場合、現在の方式を利用できない利用者が別方式へ切り替えられるようにします。「別の方法を試す」という操作から、登録済みパスキー、認証アプリ、予備キーなどを選択できる設計が有効です。

ただし、最も弱い方式へ常に簡単に切り替えられると、攻撃者もその経路を選べます。高リスク操作では一定以上の強度を持つ方式だけを提示するなど、利用者の利便性だけでなく認証保証レベルを維持する必要があります。

6. ワンタイムパスワード入力フロー

数字による一時パスワードはMFAで広く利用されていますが、小さな入力欄一つにも入力支援、有効期限、再送、試行回数、エラー表示など多数の設計判断があります。

6.1 一つの入力欄を基本にする

6桁のコードを六つの独立した入力欄へ分割するUIは視覚的には分かりやすく見えますが、貼り付け、画面読み上げ、削除、カーソル移動などの実装が複雑になります。内部的には一つの入力欄として扱い、必要であれば見た目だけ分割表示する方法を検討します。

利用者がSMSや認証アプリからコードをコピーして貼り付けられることも重要です。セキュリティを理由に貼り付けを禁止すると、手入力ミスが増え、画面拡大や支援技術を使う利用者の負担も高まります。

一時パスワード入力のコード例

<label for="otp">  6桁の認証コード </label> <input  id="otp"  name="otp"  type="text"  inputmode="numeric"  autocomplete="one-time-code"  pattern="[0-9]*"  maxlength="6"  aria-describedby="otp-help" > <p id="otp-help">  認証アプリに表示されているコードを入力してください。 </p>

6.2 有効期限を分かりやすく扱う

一時パスワードには短い有効期間がありますが、秒単位で大きなカウントダウンを表示すると、利用者を必要以上に急がせる場合があります。期限が切れたときに自然に次コードを利用できる認証アプリ型であれば、「コードが更新された場合は新しいコードを入力してください」と説明する方が分かりやすい場合があります。

SMSなどサーバーから送るコードでは、再送時に古いコードをどう扱うかを明確にします。OWASPはOTPについて短い有効期限、単回使用、厳格な試行回数制限、成功後の無効化を推奨しています。また再送時には新しいOTPを生成し、古い記録を置き換えることも推奨しています。

6.3 コード再送を安全に設計する

「コードを再送」を何度でも押せるようにすると、SMS送信費用の悪用や通知スパムにつながる可能性があります。短い待機時間を設け、一定時間後に再送できるようにし、送信回数にも適切な制御を設定します。

UIではボタンを完全に消すのではなく、「32秒後に再送できます」など現在の状態を伝えます。ただし、カウントダウンが画面読み上げソフトで毎秒通知されないようにし、必要な節目だけを利用者へ伝える配慮が必要です。

6.4 入力失敗を具体的に伝える

コードが誤っている場合は、「エラー」とだけ表示せず、「コードを確認してもう一度入力してください」のように修正方法を示します。有効期限切れの場合に技術的に区別できるなら、「コードの有効期限が切れました。新しいコードを使用してください」と具体的に案内できます。

ただし、試行回数の残数を常に詳細に公開することが望ましいとは限りません。セキュリティ担当者と協力し、利用者が修正できる十分な情報と、攻撃者へ与えない方がよい情報を分けます。

6.5 一時パスワードをログへ残さない

一時パスワードは短時間しか有効でなくても認証秘密です。デバッグログ、分析イベント、エラー監視サービスなどへ入力値をそのまま記録してはいけません。OWASPもOTP値をログへ記録せず、長期的な平文保存を避けるよう推奨しています。

デザイナーにとっても、利用者入力を分析ツールへ送信する設計では、認証フォームを除外することを確認する責任があります。「フォーム入力率を分析したい」という目的で認証コードをイベント値へ含めず、成功・失敗など秘密を含まない状態だけを計測します。

7. プッシュ承認フロー

プッシュ型MFAはコード転記の負担を減らせますが、承認行為を単純化しすぎると利用者が内容を確認せず承認する習慣を作ってしまいます。便利さと認証意図を両立する設計が必要です。

7.1 承認要求を送ったことを説明する

Web側では「スマートフォンを確認してください」と表示し、どの登録端末へ要求を送ったのか分かる範囲で示します。「iPhoneへ送信しました」のように端末名称を表示すると、複数端末を登録している利用者が迷いにくくなります。

電話番号や端末識別情報を完全な形で表示する必要はなく、本人が判断できる最小限の情報にします。要求が届かなければ再送、別方式への切り替え、端末確認などの次の行動へ進めるようにします。

7.2 承認側で要求内容を表示する

スマートフォン側では単に「ログインを承認しますか」と表示するのではなく、サービス名、要求時刻、ブラウザーまたは端末、必要に応じて概略位置などを示します。利用者が自分で開始したログインであるかを判断できる情報を提供するためです。

位置情報はIPなどから推定される場合があり、常に正確とは限りません。「東京都」などを断定的な本人位置として扱わず、「要求元のおおよその場所」として説明します。誤差によって正規利用者を不必要に不安にさせない設計が必要です。

7.3 番号照合を利用する

ログイン画面に数字を表示し、スマートフォン側で同じ数字を選択または入力させる番号照合を導入すると、突然届いた通知を反射的に承認する行動を減らせます。利用者はWeb上のログイン操作とスマートフォン上の承認要求を関連付ける必要があります。

番号照合を導入する場合は、数字が何のために表示されているかを説明します。「スマートフォンに表示された選択肢から42を選んでください」のように操作を具体化し、数字だけを大きく表示して利用者に意味を推測させないようにします。

7.4 拒否操作を明確にする

利用者が自分で開始していない要求を受け取った場合、迷わず「拒否」できる必要があります。「いいえ」「キャンセル」より、「このログインを拒否」のように結果が分かる文言が適しています。

拒否後には「パスワードが知られている可能性があります」と過度に断定せず、不審な要求が続く場合にパスワード変更やセキュリティ確認を案内します。OWASPも第一要素成功後にMFAだけ失敗する状況は、正規利用者が第二要素を利用できない場合と、攻撃者がパスワードを取得した場合の双方が考えられるため、不審な試行を通知することを勧めています。

7.5 通知疲労を防ぐ

攻撃者が繰り返しログインを試し、大量の承認要求を送ると、利用者が煩わしさから承認してしまう可能性があります。送信頻度を制限し、異常な繰り返しを検知して追加保護を適用します。

UIでも、短時間に複数要求が発生した場合に一件ずつ同じ通知を並べるのではなく、不審なログイン試行が続いていることを明確に知らせます。利用者に「承認して通知を止める」ような心理を生ませないことが重要です。

8. パスキーを利用したMFAフロー

パスキーは従来のMFAフローを短縮しながら、フィッシング耐性を高められる認証方式です。コードを受け取り別画面へ入力する方式とは異なるため、UIも従来の「第一要素→第二要素」という固定構造から見直す必要があります。

8.1 パスキーによる認証を開始する

利用者が「パスキーでログイン」を選ぶと、サーバーはランダムなチャレンジを生成し、ブラウザーへ認証要求を渡します。ブラウザーは利用可能な認証器を選択し、端末の暗証番号、指紋、顔などによる確認を行います。

この確認は通常、サービス自身が生体情報を受け取るものではありません。端末側が認証器を利用してよいかを確認し、その後暗号学的な応答をサービスへ返します。UIでは「顔情報を当社へ送信します」と誤解させないよう、端末上で本人確認が行われることを分かりやすく説明します。

8.2 サービス固有の認証によってフィッシングを防ぐ

パスキーなどWebAuthnに基づく方式では、認証資格情報がサービスのドメインと結び付けられます。そのため、偽サイトへ誘導されても、本物のサイト向け資格情報を同じように利用させることが困難になります。

これは、利用者自身が「URLをよく確認する」という注意力に依存するフィッシング対策とは性質が異なります。NISTはフィッシング耐性について、利用者の警戒心に頼らず、偽の検証者へ有効な認証秘密や認証出力を渡さない認証プロトコルの能力として説明しています。

8.3 同期可能なパスキーを扱う

現代のパスキーは、利用者の端末間で安全に同期できる場合があります。これによって新しいスマートフォンへ移行した際にも同じ資格情報を利用しやすくなり、従来の単一端末MFAより復旧体験を改善できる可能性があります。

ただし、同期可能な資格情報と、ハードウェアから持ち出せない資格情報では保証レベルが異なります。NISTの現行SP 800-63Bでは、AAL3では秘密鍵を持ち出せないことが要求されるため、同期可能な認証器はAAL3では利用できません。サービスのリスクに応じて方式を選ぶ必要があります。

8.4 クロスデバイス認証を分かりやすくする

PCでログインしながらスマートフォンのパスキーを利用する場合、QRコードなどを用いたクロスデバイス認証が利用されることがあります。利用者から見ると「PCログインなのにスマートフォンで操作する」という複数端末フローになるため、各画面で現在行うことを明確にします。

「スマートフォンでQRコードを読み取ってください」「スマートフォン上で本人確認を完了してください」「完了するとこの画面は自動的に進みます」のように段階を説明し、PC側で不要な再読み込みやボタン連打を起こさないようにします。

8.5 パスキーが使えない場合の代替経路を設計する

すべての利用者が同じ端末やブラウザーを利用するとは限らないため、パスキーだけへ移行する場合も対象環境を確認する必要があります。企業管理端末、共有端末、古い環境などでは運用上の制約が存在する場合があります。

代替方式を用意するときも、簡単なメールリンク一つで強力なパスキー認証を迂回できる構成にしないよう注意します。通常ログインと復旧・代替経路を含めた全体の攻撃面を比較する必要があります。

9. リスクベース認証と追加確認フロー

すべてのログインで毎回同じMFA操作を要求すると、利用者負担が大きくなります。サービスによっては、端末、場所、操作内容などのリスク情報を利用し、必要な場面だけ追加認証を要求する方法があります。

9.1 新しい端末で追加確認する

普段使用していない端末からログインした場合、追加のMFAを要求する方法があります。通常利用では認証負担を減らしながら、不審な環境では確認を強化できます。

ただし、「新しい端末」という判断は端末情報の取得方法に依存し、ブラウザー設定やプライバシー保護によって変化する場合があります。利用者へ「不正アクセスです」と断定せず、「この端末では追加確認が必要です」と中立的に説明します。

9.2 不審な場所から追加確認する

通常と大きく異なる地域やネットワークからログインした場合、追加確認を求めることがあります。しかしVPN、携帯回線、企業ネットワークなどによって位置推定は変化するため、位置だけで本人性を判断してはいけません。

NISTも地理的位置やIPなどの詐欺指標を追加リスク管理に使用できる一方、それらは認証要素そのものを代替しないとしています。リスク情報はMFAを省略する魔法の本人確認ではなく、追加制御を決める補助情報として扱います。

9.3 高リスク操作だけ再認証する

ログイン済みであっても、パスワード変更、メールアドレス変更、MFA解除、銀行口座変更、管理権限取得などの重要操作では追加認証を要求します。これを段階的認証またはステップアップ認証として扱うことがあります。

NISTの現行ガイドラインでも、現在のセッションより高い認証保証レベルが必要になった場合、ステップアップ認証によってセッションの保証レベルを引き上げられることが説明されています。

9.4 追加確認の理由を説明する

突然MFA画面へ移動すると、利用者はセッションが切れたのか、操作に失敗したのか分からなくなります。「メールアドレスを変更するため、もう一度本人確認をしてください」のように理由を明示します。

理由を説明すれば、利用者は認証完了後に元の操作へ戻ることを予測できます。認証成功後に設定トップへ戻すのではなく、可能な限り中断した操作へ戻します。

9.5 リスク判定を利用者へ押し付けない

「このログインは危険度72％です」のような内部スコアを利用者へ表示しても、何をすべきか分かりません。リスク判定はシステム側で行い、利用者には必要な行動だけを分かりやすく提示します。

一方、不審な操作を本人が確認する必要がある場合は、端末、時刻、概略位置など判断に役立つ具体情報を提示します。内部モデルの数値ではなく、利用者が意味を理解できる事実を表示します。

10. MFA失敗・再試行フロー

MFAでは失敗状態が必ず発生します。入力ミス、コード期限切れ、端末通信失敗などの日常的な問題と、攻撃者による大量試行を同じ方法で扱わず、安全な回復と攻撃防止を両立させます。

10.1 一度の入力ミスでロックしない

利用者は数字を一桁間違える、別アカウントのコードを見るなどの単純なミスをします。一度の失敗ですぐアカウント全体をロックすると、正規利用者の負担が大きくなります。

一定回数までは安全に再入力できるようにしながら、無制限の試行は許可しません。具体的な回数や遅延方式はリスクと認証方式に応じてセキュリティ担当者が決定します。

10.2 試行回数を制限する

短い数字のOTPは可能な組み合わせ数が限定されるため、無制限に試せる状態では総当たり攻撃へ弱くなります。OTPの有効時間だけでなく、試行回数の制限が必要です。

OWASPもOTPについて厳格な試行回数制限を推奨しています。コードが正しく検証された場合には再利用できないよう直ちに無効化する必要があります。

10.3 通信失敗と認証失敗を区別する

ネットワークが切れてサーバーへ確認要求を送信できなかった場合と、入力したコードが間違っていた場合では、利用者が取るべき行動が異なります。「認証に失敗しました」だけですべてをまとめると、正しいコードを何度も入力し直す可能性があります。

通信エラーでは「接続を確認してもう一度お試しください」、認証値の不一致では「コードを確認してください」と、修正可能な範囲で原因を区別します。ただし内部システムの詳細な障害情報をそのまま公開する必要はありません。

10.4 別方式へ切り替えられるようにする

認証アプリを開けない、セキュリティキーを持っていないなどの場合に、利用者が登録済みの別方式へ切り替えられるようにします。最初から復旧フローへ飛ばすより、既存認証器を使えるならその方が安全で簡単です。

「別の方法を試す」は認証画面上で見つけやすく配置します。ただし、SMSなど弱い方式が登録されている場合、高リスク操作では切り替えを制限するなど、要求される認証強度を維持します。

10.5 不審なMFA失敗を通知する

正しいパスワードが入力された後に第二要素だけが繰り返し失敗する場合、正規利用者が端末を利用できない可能性だけでなく、攻撃者がパスワードを取得している可能性もあります。

OWASPはこうした状況で、利用者へ失敗したログインを通知し、本人が認識していない場合はパスワード変更を促すことを推奨しています。通知には時刻、ブラウザー、概略位置など判断材料を含めることができます。

11. MFA復旧と認証要素変更フロー

MFAの中でも最も危険な設計箇所の一つが復旧です。通常ログインを強力にしても、「スマートフォンをなくしました」という申告だけでMFAを解除できれば、攻撃者は通常ログインではなく復旧経路を狙います。

11.1 予備認証器を優先する

主要端末を失った場合でも、別の登録済み認証器、予備セキュリティキー、パスキーなどが利用できるなら、それを最初の復旧方法として提示します。すでに登録済みの強力な証拠を利用できれば、新しい本人確認手続きを追加する必要を減らせます。

登録時に複数認証器を推奨することは、復旧フローそのものを簡潔にする効果があります。高重要度アカウントでは、最初から二つの独立した認証器を登録する運用も検討できます。

11.2 回復コードを利用する

回復コードは、MFA端末を利用できないときの一回限りの秘密として使用できます。通常は登録時に複数のコードを発行し、利用者が安全な場所へ保存します。

回復コードもアカウントへのアクセスを可能にする重要な秘密であるため、平文のまま不用意に扱ってはいけません。利用済みコードは再使用できないようにし、残りコードが少なくなった場合に再生成できる仕組みを用意します。

11.3 MFAリセットを簡単にしすぎない

メールへリンクを送るだけでMFAを完全解除できる場合、そのメールアカウントが侵害されればMFAを迂回される可能性があります。アカウントの価値やリスクに応じて、複数の本人確認情報や待機期間、管理者確認などを組み合わせます。

OWASPもMFA復旧は攻撃者にとってMFAを迂回する経路になり得るため、通常認証と同等の慎重さが必要だとしています。復旧しやすさだけを最適化してはいけません。

11.4 認証要素変更前に再認証する

登録電話番号、認証アプリ、パスキーなどを変更するときは、ログイン済みセッションがあるという理由だけで許可しません。セッション自体が盗まれている可能性があるため、既存の認証器を用いた再認証を要求します。

OWASPはMFA要素変更を高リスク操作として扱い、既存の登録要素で再認証し、新しい端末や異常な場所などのリスクも考慮し、変更時には別経路で利用者へ通知することを推奨しています。

11.5 要素変更を利用者へ通知する

新しい認証アプリ、電話番号、パスキー、セキュリティキーが登録された場合は、「認証方法が追加されました」と通知します。本人の操作でなければ、迅速にアカウント保護へ進める導線を提供します。

通知内で単に「心当たりがない場合はお問い合わせください」とするだけでなく、可能であれば「セキュリティ設定を確認」「すべてのセッションからログアウト」など、安全な次の行動へ直接移動できるようにします。

12. MFAとセッション・再認証

MFAが成功した後も、認証保証をどのくらい維持するかを決める必要があります。毎操作でMFAを要求すれば安全に見えますが利用不能になり、長期間再認証しなければ盗まれたセッションが悪用される可能性があります。

12.1 セッション有効期間を設定する

認証成功後にはセッションが発行されますが、永続的なログイン状態を無条件に維持しないようにします。サービスのリスクに応じて、全体の有効期間と操作がない場合の無操作タイムアウトを設定します。

NIST SP 800-63Bでは認証保証レベルに応じた再認証要件が定義されており、例えばAAL3では再認証全体の期限が12時間以内、無操作タイムアウトは15分以内が推奨されています。これはすべての民間サービスへそのまま適用する数字ではありませんが、認証強度とセッション寿命を一体として考える必要性を示しています。

12.2 「この端末を信頼する」を慎重に扱う

「30日間この端末では確認しない」といった機能は利用者負担を減らせます。しかし、「信頼」という曖昧な言葉だけでは、その端末に何が保存されるのか、どの操作までMFAが省略されるのか理解しにくくなります。

共用PCや公共端末では有効にしないよう説明し、いつでも登録済み端末を確認・削除できるようにします。高リスク操作では信頼済み端末でも再認証を要求するなど、ログイン時の便利さと重要操作の保護を分けます。

12.3 高リスク操作で再認証する

アカウント削除、支払先変更、MFA解除、パスワード変更など、結果の大きい操作は、既存セッションだけで実行させない方が安全な場合があります。操作直前に適切な認証器で再確認します。

このとき利用者へ「セッションの保証レベルが不足しています」と技術用語を表示するのではなく、「支払先を変更するため、本人確認をもう一度行ってください」と目的を説明します。

12.4 再認証後に操作状態を保持する

長いフォームを入力した最後に再認証が必要になり、MFA終了後に入力内容がすべて消えると大きな不満につながります。安全に保持できる入力については、再認証前の状態を保存して操作へ戻します。

ただし、秘密情報やカード情報などを不用意に一時保存することは別のリスクになります。保持可能な項目と再入力が必要な項目を事前に決め、利用者へ説明します。

12.5 セッションを利用者自身で管理できるようにする

アカウント設定では、現在ログインしている端末やセッションを確認し、不明なセッションを終了できるようにすると有効です。端末名、最終利用時刻、概略位置など、本人が判断しやすい情報を提供します。

認証要素を変更した場合や不正アクセスが疑われる場合には、他のセッションを終了する選択肢を提供します。MFAだけでなくセッション管理まで含めて、利用者がアカウントを保護できる設計にします。

13. MFAのUI・アクセシビリティ設計

MFAはアカウントへアクセスする入口であるため、操作できない利用者に代替経路がなければサービス全体を利用できません。セキュリティだけでなく、入力方法、視覚、認知、端末環境などの違いを考慮します。

13.1 コード入力を支援する

一時パスワード入力欄では、数字キーボードを表示しやすいinputmode="numeric"や、対応環境でコード補完を利用できるautocomplete="one-time-code"などを検討します。利用者がコピー・貼り付けできることも重要です。

六つの入力欄を自動的に移動する独自実装では、画面読み上げ、音声入力、削除操作などを必ず検証します。視覚的なデザインを優先して標準的なフォーム操作を壊さないようにします。

13.2 時間制限を過度に厳しくしない

認証コードに有効期限が必要でも、UI操作そのものに不要な時間制限を追加しないようにします。利用者が支援技術を使っている場合や、別端末からコードを確認している場合には一般的な利用者より時間が必要なことがあります。

コードが切り替わった場合に最初からフローをやり直させるのではなく、新しいコードをそのまま入力できるようにするなど、安全性を維持しながら時間的負担を減らします。

13.3 色だけで成功・失敗を表さない

正しいコードを緑、誤りを赤だけで表示すると、色を認識しにくい利用者へ状態が伝わりません。「コードを確認してください」「認証が完了しました」と文字でも明確に伝えます。

入力欄近くのエラー表示とページ全体の状態通知を適切に組み合わせ、画面読み上げソフトでも変化を確認できるようにします。

13.4 認証方式を一つに固定しすぎない

SMSだけ、スマートフォンアプリだけなど特定の端末や能力へ依存すると、その方式を利用できない人がサービスへアクセスできなくなる場合があります。対象利用者の環境を確認し、必要に応じて複数の安全な方法を提供します。

ただし、アクセシビリティのための代替経路が極端に弱い認証になってはいけません。安全性を下げた「例外」を作るのではなく、異なる操作方法でも同程度の保証を持つ認証方式を用意することが理想です。

13.5 認証フローを支援技術で実際に検証する

デザインデータ上でラベルやエラーが存在するだけでは十分ではありません。キーボードだけでMFA登録とログインを完了できるか、画面読み上げソフトでコード入力、エラー、再送、方式変更を理解できるかを実際に検証します。

特に外部の認証サービスやOS標準ダイアログへ移動するフローでは、画面間の切り替わりが利用者へ分かるかを確認します。認証成功率だけでなく、どの利用者が途中でアクセスできなくなるかを品質指標に含める必要があります。

14. MFAを実装する際のセキュリティ設計

安全なMFAはフロントエンドだけでは実現できません。サーバー側のチャレンジ管理、試行制限、秘密情報の保存、セッション、ログ、APIなどを含めて実装する必要があります。

14.1 MFA途中状態をサーバーで管理する

第一要素が成功して第二要素を待っている状態を、通常の認証済みセッションと区別します。MFA検証前の一時セッションでは、第二要素確認やログアウトなど限定された機能以外へアクセスさせません。

フロントエンドで「まだMFA画面だから保護ページを表示しない」という制御だけでは不十分です。API側でも認証保証状態を確認し、直接リクエストされた場合に保護データを返さないようにします。

MFA状態確認の擬似コード例

function authorizeRequest(session, requiredLevel) {  if (!session.userId) {    throw new Error('AUTHENTICATION_REQUIRED');  }  if (session.authenticationLevel < requiredLevel) {    throw new Error('STEP_UP_REQUIRED');  }  return true; }

14.2 OTPを安全に生成する

サーバー発行型OTPでは、予測可能な乱数を使用してはいけません。暗号学的に安全な乱数生成器を使用し、十分な長さ、有効期間、試行回数を設定します。

OTPは短い寿命であっても秘密情報として扱います。OWASPはOTPをログへ残さず、長期平文保存を避け、成功時には無効化し、再送時には新しいコードへ置き換えることを推奨しています。

一時コード生成の概念例

import crypto from 'node:crypto'; function createOtp() {  return crypto.randomInt(100000, 1000000).toString(); }

14.3 チャレンジを一回限りにする

パスキーなどの暗号学的認証では、サーバーが新しいランダムチャレンジを発行し、その特定の認証試行に対する署名を検証します。同じチャレンジを長期間再利用すると、認証プロトコルの安全性を損ないます。

チャレンジには短い有効期限を設定し、成功・失敗条件に応じて使用済み状態を管理します。リプレイ攻撃への耐性は強力な認証方式の重要な要件であり、NISTもAAL2以上の認証器にリプレイ耐性に関する要件を定めています。

14.4 認証APIにもMFAを適用する

Web画面ではMFAを要求しているのに、別のモバイルAPIや古い認証APIではパスワードだけでログインできる場合、攻撃者はMFA画面を迂回できます。OWASPも複数の認証経路を持つサービスでは、すべての経路へMFAまたは同等の保護を適用する必要があると指摘しています。

認証フローを設計するときは、Webブラウザーだけでなく、モバイルアプリ、管理画面、API、旧システム、サポートによる復旧など、アカウントへアクセスできるすべての入口を洗い出します。

14.5 認証イベントを監視する

MFA登録、MFA失敗、復旧、認証器変更、MFA無効化などの重要イベントを監査ログとして記録します。ただし、OTPそのもの、回復コード、秘密鍵など認証秘密をログへ保存してはいけません。

異常なMFA失敗の増加、短時間での多数のコード要求、認証器の頻繁な変更などを監視すれば、攻撃や実装不具合を発見しやすくなります。分析用イベントとセキュリティ監査ログの目的を分けて設計することも重要です。

15. MFAフローにおけるデザイナーの責任

MFAの暗号方式やサーバー実装をデザイナーが単独で決める必要はありません。しかし、利用者がどの方式を選択し、どの情報を確認し、問題発生時にどこへ進むかは明確なUX設計です。認証を「開発側が作るログイン画面」として扱わないことが重要です。

15.1 正常系だけでなく例外系まで設計する

MFA画面を作る際には、正常なコード入力だけでなく、誤入力、有効期限切れ、コード未着、端末紛失、通信失敗、認証器故障、アカウント復旧まで状態を洗い出します。実際の利用者が問い合わせを必要とするのは、多くの場合この例外経路です。

フロー図では、それぞれの状態からどこへ移動できるかを明確にし、行き止まりを作らないようにします。ただし「困ったらMFAを解除」という安全性を下げる万能経路を作らず、適切な本人確認へ接続します。

15.2 認証方法の強弱を理解してUIへ反映する

すべてのMFA方式を同じ価値の選択肢として横並びにすると、利用者は最も簡単そうな方法だけを選び、より安全な方式が普及しない可能性があります。安全性と使いやすさの両方を考慮し、推奨方式を明確にします。

例えばパスキーを主要方式とし、認証アプリを代替、より弱い方式を限定的な復旧手段として扱うなど、製品の脅威モデルに応じた情報階層を作ります。技術的な強度はセキュリティ担当者と共同で判断します。

15.3 セキュリティ警告を理解可能な文章にする

「認証器検証失敗」「AAL不足」「FIDOチャレンジ異常」のような内部用語を利用者へそのまま表示してはいけません。「本人確認を完了できませんでした」「この操作には追加の本人確認が必要です」のように、利用者が次の行動を判断できる文章へ変換します。

一方で、すべてを「エラーが発生しました」と曖昧にすると修正できません。利用者が安全に知ることのできる範囲で、問題と解決方法を具体的に伝えます。

15.4 MFA成功率だけでなく復旧率を確認する

製品指標として通常MFAの成功率だけを見ると、端末を紛失した利用者や認証器を変更した利用者の問題が見えません。登録完了率、通常ログイン成功率、別方式切り替え率、復旧成功率、問い合わせ発生率などを組み合わせます。

ただし、成功率を高めるために認証要件を弱くしてはいけません。安全性上必要な制約を維持しながら、説明不足や不要な操作によって発生している失敗を減らすことがUX改善の目的です。

15.5 セキュリティ・開発・品質保証と共同で検証する

MFAはUIだけで完成しないため、デザイナー、セキュリティ担当者、実装担当者、品質保証担当者が共同でフローを確認します。デザイナーは情報提示と操作、セキュリティ担当者は脅威と保証レベル、実装担当者は認証プロトコルと状態管理、品質保証担当者は実際の環境での動作を重点的に確認します。

特に、正常ログイン、コード誤入力、端末紛失、新規端末、認証器変更、復旧、不正プッシュ、セッション期限切れなどをシナリオとしてテストします。MFAは「正しい利用者を通す」だけでなく、「攻撃者を通さず、正しい利用者が問題から安全に復帰できる」ことまで確認して初めて完成したフローになります。

おわりに

MFAフローとは、パスワード入力後に一時コードを一回入力させるだけの画面ではありません。認証方式の選択、初回登録、第一要素、追加認証、成功、失敗、別方式への切り替え、再認証、認証器変更、端末紛失、アカウント復旧まで含めた認証体験全体を指します。通常ログインだけが安全でも、要素変更や復旧経路が弱ければ、攻撃者は最も突破しやすい経路を利用するため、すべての入口を一つのセキュリティ境界として設計する必要があります。

また、MFAの強度は認証要素の数だけでは決まりません。一時パスワード、SMS、プッシュ承認、セキュリティキー、パスキーでは、フィッシング、リプレイ、端末紛失などへの耐性が異なります。特に現代の認証設計では、利用者が秘密情報を偽サイトへ入力する方式だけに依存せず、パスキーなどフィッシング耐性を持つ暗号学的認証方式を選択肢として検討することが重要になっています。

UIデザイナーの責任は、暗号アルゴリズムを実装することではなく、利用者が現在何を確認しているのかを理解し、安全な認証方式を迷わず使え、問題が起きても危険な近道を使わず復帰できる体験を設計することです。MFAの安全性と操作性は対立するものではありません。不要な入力を減らし、状況を明確に説明し、フィッシング耐性の高い方式を優先し、安全な復旧手段を最初から組み込むことで、認証強度を高めながら利用者の負担を減らすことができます。