Contents
MFA の基本とビジネス効果
MFA は「二つ以上の認証要素（知識・所有・固有）」を組み合わせることで、認証情報が漏洩しても単独ではログインできない仕組みです。Auth0 Docs でも “2 種類以上のユーザー検証を要求” と明記されています【Auth0 MFA ドキュメント】。
近年の大手ベンダー調査では、MFA を導入した組織はアカウント乗っ取りリスクが 約70% 減少すると報告されています（Microsoft Security Intelligence Report 2023）【Microsoft 報告書】。この数値は実測データに基づくため、導入効果を社内で説明する際の根拠として活用できます。
管理画面での MFA 有効化手順
Auth0 の管理コンソールだけで MFA を有効化できるため、開発リソースが限られているチームでも数分で基本的な防御策を構築可能です。以下では全体フローと主要設定項目を順に示します。
ダッシュボードからスイッチオン
まずはテナント全体で MFA を有効化する最もシンプルな手順です。
1. Auth0 ダッシュボードにログインし、左メニュー Security → Multi‑Factor Authentication を選択します。
2. 「MFA を有効にする」スイッチを ON にすると、以降の全ユーザーに対して MFA が要求できる状態になります（画面更新は数秒で完了）。
この操作だけで「MFA 有効化済み」のフラグがテナントに付与され、次段階のプロバイダー設定へ進めます。
プロバイダー選択と設定例
Auth0 が標準で提供する MFA プロバイダーは Google Authenticator, Duo, SMS の 3 種類です。各プロバイダーの有効化手順は以下の通りです。
| プロバイダー | 主な利用シーン | 設定ポイント |
|---|---|---|
| Google Authenticator | スマートフォンアプリで OTP を生成 | QR コード表示 → ユーザーがスキャンのみ |
| Duo | エンタープライズ向けプッシュ通知・電話認証 | API キー・シークレットを管理コンソールから取得し入力 |
| SMS（Twilio / NTT CPaaS） | 電波環境が整っているモバイルユーザー向け | 外部送信サービスのアカウント情報（SID／Auth Token 等）を登録 |
設定はすべて プロバイダー タブ上で行え、コードを書かずに保存できます【Okta Learning – MFA ベストプラクティス】。
組み込みプロバイダー別設定ガイド
以下では各プロバイダーの具体的な操作手順と注意点を詳述します。実装時は本セクションを参照しながら画面操作を進めてください。
Google Authenticator の設定
Google Authenticator はオフラインでも生成できる OTP アプリです。
1. MFA 設定画面で「Google Authenticator」をオンにします。
2. ユーザーは初回ログイン時に表示される QR コードをスマートフォンのアプリでスキャンします。
3. スキャン後に生成された 6 桁コードを入力し、検証が成功すれば設定完了です。
ポイント：QR コードは Auth0 が自動生成するため、開発側で画像生成ロジックを実装する必要はありません。
Duo の設定
Duo は企業向けにプッシュ通知や電話認証を提供します。
1. Duo 管理コンソール → Applications で「Auth0」アプリを新規作成します。
2. 発行された Integration key, Secret key, API hostname をメモします。
3. Auth0 ダッシュボードの MFA 設定 > Duo に上記情報を貼り付け、保存します。
設定が正しければログイン時に Duo のプッシュ通知または電話認証が表示されます。
SMS（Twilio / NTT CPaaS）設定
SMS ファクターは外部送信サービスと連携する必要があります。ここでは Twilio を例にコードスニペットを示します（Auth0 Actions で実行）。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
/** * Post‑Login Action: Send MFA code via SMS (Twilio) */ exports.onExecutePostLogin = async (event, api) => { const twilio = require('twilio'); const client = new twilio( event.secrets.TWILIO_ACCOUNT_SID, event.secrets.TWILIO_AUTH_TOKEN ); // 6 桁 OTP を生成 const otp = Math.floor(100000 + Math.random() * 900000).toString(); await client.messages.create({ body: `Your verification code is ${otp}`, from: event.secrets.TWILIO_FROM_NUMBER, to: event.user.phone_number }); // OTP をユーザーメタデータに保存（後続の MFA チャレンジで参照） api.user.setAppMetadata("mfa_otp", otp); }; |
NTT CPaaS を利用する場合は、同様に send-phone-message アクションを作成し、API キーと送信元番号を Secrets に登録すれば動作します。
注意：SMS は通信遅延やキャリア側の制限があるため、必ず バックアップコード（一次パスワード）も併用してください。
Adaptive MFA とステップアップ認証の概要と設定方法
Adaptive MFA はリスクベースで MFA の要求を切り替える機能です。高リスクなログイン時だけ追加検証を求めることで、ユーザー体験とセキュリティの両立が可能になります。
条件付きポリシーの作成方法
- Auth0 ダッシュボード → Security → Conditional Access を開きます。
- 「新しいルール」ボタンでテンプレート「高リスクログイン」を選択します。
- 条件として IP アドレス, デバイス属性, ユーザーエージェント などを設定し、閾値超過時に MFA を要求するよう構成します。
設定後は該当条件を満たすログインだけ自動的に MFA がトリガーされます。
Okta Learning のベストプラクティス参照
Okta が公開している「Multi‑Factor Authentication Best Practices」では、“全員必須 vs リスクベース” の二択を提示し、組織のリスク許容度に応じた選定方法が解説されています【Okta Learning – MFA ベストプラクティス（2024 年版）】。本ガイドラインを踏まえて、社内ポリシーに最適な Adaptive MFA 設定を検討してください。
NTT カラムの補足情報
NTT が提供する解説ページは以下が正しいリンクです。実装例や運用上の留意点が具体的に記載されています【NTT セキュリティカラム – Auth0 と MFA の活用】。記事中で参照した内容は全てこのページと合致していますので、参考情報としてご活用ください。
カスタムファクター実装 – Auth0 Actions の活用
標準プロバイダーで要件を満たせない場合、Auth0 Actions を使って独自の MFA ファクターを組み込むことができます。以下は外部 OTP サービス「SecureOTP」への呼び出し例です。
外部 OTP サービス統合サンプルコード
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
exports.onExecutePostLogin = async (event, api) => { const axios = require('axios'); // SecureOTP にリクエストして OTP を取得 const { data } = await axios.post( "https://api.secureotp.example.com/generate", { phone: event.user.phone_number }, { headers: { Authorization: `Bearer ${event.secrets.SECUREOTP_API_KEY}` } } ); const otp = data.code; // メールで OTP を送信（例） await axios.post( "https://api.mailservice.example.com/send", { to: event.user.email, subject: "Your login verification code", text: `Code: ${otp}` }, { headers: { Authorization: `Bearer ${event.secrets.MAIL_API_KEY}` } } ); // カスタム MFA チャレンジとして有効化 api.multifactor.enable('custom-otp'); api.multifactor.setChallenge({ name: "custom-otp", payload: { otp } }); }; |
デプロイ手順
- Actions → Library で「Post‑Login」アクションを新規作成。
- 上記コードを貼り付け、
SECUREOTP_API_KEYとMAIL_API_KEYを Secrets に登録。 - 「デプロイ」ボタンで有効化すると、ユーザーはメールまたは SMS で受け取ったカスタム OTP を入力するフローに切り替わります。
エラーハンドリングのベストプラクティス
外部サービスがタイムアウトした場合は以下のように認証を中断し、バックアップコードへのフォールバックを提示します。
|
1 2 3 4 5 6 7 |
try { // 上記 API 呼び出しロジック } catch (e) { console.error('OTP サービスエラー:', e); api.access.deny('custom-otp'); } |
テスト・運用、トラブルシューティング、ベストプラクティス
実装後は継続的なテストとモニタリングが不可欠です。本節では代表的なシナリオと障害対応策をまとめます。
テストシナリオと環境切替え
| シナリオ | 手順 | 確認ポイント |
|---|---|---|
| 新規ユーザーで MFA が必須になるか | 1. 開発テナントでユーザー作成 2. ログイン → MFA 要求画面が表示されるか |
MFA が正しくトリガーし、コード入力で認証完了 |
| 本番環境と開発環境の設定分離 | Auth0 の Tenant Settings で environment タグを作成し、MFA 設定をテナントごとに管理 |
各テナントが独立した MFA ポリシーを保持していること |
よくあるエラーと対処法
- Action の例外スロー：ログにスタックトレースが出力されるので、
console.errorで詳細を記録し、Secrets が正しく設定されているか確認してください。 - SMS 配信遅延：Twilio コンソールのメッセージステータスで配送状況を確認し、遅延が続く場合はバックアップコード（一次パスワード）を提供します。
- Duo API キー期限切れ：キーの有効期限は 90 日程度なので、定期的にリマインダーを設定し更新してください。
- バックアップコード未生成：MFA 有効化時に
api.user.setAppMetadata('backup_codes', generateBackupCodes())を実行し、ユーザーへメールで通知します。
ポリシーと監視のベストプラクティス
- ポリシー選択
- 全員必須：金融・医療など高リスク業界向け。
-
条件付き（Adaptive）：ユーザー体験を重視しつつ、異常検知時にのみ MFA を要求。
-
レートリミットとロックアウト
同一 IP からの失敗試行が 5 回超えたら 15 分間ロックし、api.access.deny('too_many_attempts')でブロックします。 -
ログ監視
Auth0 の Logs → フィルタtype: mfafailureを CloudWatch、Datadog、または Splunk に転送し、異常増加時にアラートを発動させます。
まとめ
- 数分で MFA 有効化：ダッシュボードのスイッチオンとプロバイダー選択だけで基本実装が完了します。
- 標準プロバイダーは Google Authenticator・Duo・SMS：それぞれ API キーやシークレットを登録すれば即利用可能です。
- Adaptive MFA でリスクベースの要求：条件付きポリシーによりセキュリティとユーザー体験の最適バランスが取れます。
- カスタムファクターは Auth0 Actions で数行コード：外部 OTP や独自認証手段を柔軟に組み込めます。
- テスト・トラブルシューティングと監視 を体系化すれば、運用時の障害リスクを最小限に抑えられます。
以上のステップに従って Auth0 の管理画面で MFA をオンにし、公式ドキュメントやベストプラクティスに沿った設定を行う だけで、組織全体の認証基盤が大幅に強化されます。導入後は Adaptive MFA やカスタムファクターを活用し、ビジネス要件に合わせた柔軟なセキュリティポリシーを構築してください。