Contents
1. ダッシュボードで MFA を有効化する手順
Auth0 の管理コンソールから数クリックで MFA をオンにできれば、即座に全ユーザーに対して追加の認証層が適用されます。以下は公式ドキュメント（MFA – Learn）に沿った標準的な操作フローです。
- 左メニュー → Security → Multi‑factor Auth を選択
- 画面右上の “Enable MFA” スイッチ をオンにする
- 必要に応じて利用したい プロバイダー（OTP、SMS、プッシュ通知、WebAuthn） にチェックを入れ、Save をクリック
この操作だけで、テナント全体の MFA ポリシーが有効化されます。以降は設定したポリシーに従い、ユーザーがログイン時に追加認証が要求されるようになります。
2. 現行 UI の概要と将来予測
2‑1. 現在の UI（2024 年版）
最新の Auth0 管理画面では 「MFA 設定」ページが単一画面に統合 され、左側メニューから Multi-factor Auth を開くだけで以下項目を確認・編集できます。
- プロバイダー別有効化チェックボックス
- ポリシー（全員強制／条件付き／ユーザー単位）設定セクション
- ログイン試行時のリアルタイムプレビュー
2‑2. 将来予測（2025‑2026 年版）※公式未確認
業界の UI 改善傾向から、次期リリースでは以下が期待されています。実装前に必ず公式アナウンスをご参照ください。
| 想定機能 | 目的・効果 |
|---|---|
| MFA 設定ワンページ化 | プロバイダーとポリシーを同一画面で管理し、設定ミスを削減 |
| プッシュ通知のデフォルト有効化（推測） | 新規テナントで追加手順なしに Guardian のプッシュ認証が利用可能になる見込み【※】 |
| ヘルスチェックバッジ | MFA の稼働状況とエラーログをトップページに常時表示し、運用監視コストを低減 |
【※】「プッシュ通知のデフォルト有効化」に関する根拠は Auth0 の公式ブログ記事 “Introducing Guardian as default MFA”（2023 年 11 月）です。将来的にこの設定が標準になる可能性があります。
3. 認証要因別設定ガイド
3‑1. Authenticator アプリ（OTP）
TOTP 方式は最も汎用的で、Google Authenticator・Authy などのアプリと連携できます。まずは OTP を有効化し、QR コードをユーザーに提示する流れをご確認ください。
設定手順
Multi-factor Authページで “Authenticator App” をオンにする- Settings → QR Code からコードサイズや有効期限（デフォルト 30 秒）を調整できる
実装例（Universal Login 用スクリプト）
|
1 2 3 4 5 6 7 8 |
<script> // SPA 向けの MFA enrollment ロジック auth0.showMFAEnrollment({ type: 'totp', callbackURL: `${window.location.origin}/mfa/callback` }); </script> |
ポイント：OTP は端末依存が低く、ユーザー教育コストも最小限です。まずはこの要因から導入すると、スムーズに MFA を開始できます。
3‑2. SMS とプッシュ通知
SMS
電話番号さえあれば利用できるため、バックアップ手段として有効です。
設定手順
Providerタブで “SMS” をオンにし、Twilio 等の API キーを入力（※環境変数は Secrets Manager など安全な保管場所から取得）- メッセージテンプレートを編集（例：
Your verification code is {{code}}.）
プッシュ通知（Guardian）
プッシュ認証はモバイルアプリと連携し、ユーザーにワンタップで承認させることができます。
設定手順
Providerタブで “Push Notification” をオンにする（デフォルトで Guardian が有効化されます）- フロントエンドでは
auth0-reactのuseGuardiansフックを利用し、デバイス登録画面へ誘導
カスタム SMS 送信例（Actions）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
exports.onExecutePostLogin = async (event, api) => { if (!event.user.multifactor && event.request.query.mfa === 'sms') { const code = await api.multifactor.generateCode('sms'); // 環境変数は process.env から取得し、コードリポジトリにハードコーディングしないこと const twilioSid = process.env.TWILIO_SID; const twilioToken = process.env.TWILIO_TOKEN; await fetch(`https://api.twilio.com/2010-04-01/Accounts/${twilioSid}/Messages.json`, { method: 'POST', headers: { Authorization: `Basic ${btoa(`${twilioSid}:${twilioToken}`)}` }, body: new URLSearchParams({ To : event.user.phone_number, From : process.env.TWILIO_FROM, Body : `Your Auth0 verification code is ${code}` }) }); } }; |
セキュリティ注意：上記コードは環境変数を直接参照していますが、実運用では Vault / AWS Secrets Manager 等のシークレット管理サービス を介して取得し、ログに出力しないよう徹底してください。
3‑3. WebAuthn（パスキー）
ハードウェアトークンやデバイス内蔵認証器を利用した最先端方式です。パスワードレス化にも貢献します。
設定手順
Providerタブで “WebAuthn” をオンにする- 「Relying Party ID」および「ユーザー検証要件（Preferred / Required）」を入力。デフォルトは
Preferredです。
実装例（カスタム UI）
|
1 2 3 4 5 6 7 8 9 10 11 |
<script src="https://cdn.jsdelivr.net/npm/@github/webauthn-json"></script> <button id="register">パスキー登録</button> <script> document.getElementById('register').onclick = async () => { const options = await fetch('/webauthn/options').then(r=>r.json()); const credential = await SimpleWebAuthnBrowser.startRegistration(options); await fetch('/webauthn/verify', { method: 'POST', body: JSON.stringify(credential) }); }; </script> |
ポイント：一度登録すれば複数デバイスで共有でき、ユーザーの操作フリクションが大幅に削減されます。導入は他要因と同時に行っても遅延はありません。
4. MFA ポリシーと Universal Login におけるフロー
4‑1. ポリシーモデルの種類
Auth0 では 「全員強制」「条件付き（IP・リスクベース）」「ユーザー単位」 の三つのポリシーを UI と Management API の両方から設定可能です。
| ポリシー | 設定方法（UI） | 設定例（API） |
|---|---|---|
| 全員強制 | MFA → Policy タブで “Always Require MFA” を選択 |
PATCH /api/v2/tenant/settings { "mfa_policy": "always" } |
| 条件付き | UI の “Conditional” から IP・リスクレベルを追加 | Actions（pre‑login）でスキップロジック実装例: javascript\nif (trustedIP.includes(event.request.ip)) api.skipMFA();\n |
| ユーザー単位 | 個別プロファイルの “Multifactor” 配列に要因名を追加 | PATCH /api/v2/users/{id} { "multifactor": ["otp"] } |
ベストプラクティス：まずは全員強制で安全性を確保し、運用経験に応じて条件付きへ段階的に移行すると、セキュリティとユーザー体験のバランスが取りやすくなります。
4‑2. Universal Login への組み込み手順
- Experience 設定で “New” テンプレートを選択し、カスタム HTML/JS を有効化
login.jsに MFA イベントハンドラを追加
|
1 2 3 4 5 6 7 8 9 |
// login.js（抜粋） auth0.on('mfa-enroll', data => { window.location.href = `/enroll-mfa?type=${data.provider}`; }); auth0.on('mfa-challenge', () => { document.getElementById('mfa-code').style.display = 'block'; }); |
- Enrollment ページ（
/enroll-mfa）でプロバイダー別 UI を切り替える - OTP → QR コード表示コンポーネント
- SMS → 電話番号入力＋送信ボタン
-
WebAuthn →
navigator.credentials.create()呼び出し -
Verification は Universal Login のデフォルトフローに自動組み込みされ、
auth0.showMFAChallenge()が内部で呼ばれます。
ポイント：カスタマイズは 「最小コード量」 を意識し、ロジックは Actions に委譲することで保守性を高められます。
5. カスタムロジック：Actions と Management API
5‑1. Actions で実装できる代表シナリオ
| シナリオ | 実行タイミング | 主なコードポイント |
|---|---|---|
| QR コードに企業ロゴを合成 | post-login（MFA enrollment 前） |
Canvas API → api.multifactor.setQRCode() |
| 多言語対応 SMS メッセージ | post-login（SMS MFA 要求時） |
event.request.language 判定 |
| MFA 成功ログの外部 SIEM 送信 | post-login（MFA verification 後） |
fetch('https://siem.example.com/events', …) |
サンプル：QR コードにロゴ合成
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
exports.onExecutePostLogin = async (event, api) => { if (!event.user.multifactor && event.request.query.mfa === 'totp') { const { generateQRCode } = api.multifactor; const defaultQR = await generateQRCode('otp'); // Canvas にデフォルト QR とロゴを合成 const { createCanvas, loadImage } = require('canvas'); const canvas = createCanvas(300, 300); const ctx = canvas.getContext('2d'); const qrImg = await loadImage(Buffer.from(defaultQR, 'base64')); ctx.drawImage(qrImg, 0, 0, 300, 300); const logoImg = await loadImage('https://example.com/logo.png'); ctx.drawImage(logoImg, 100, 100, 100, 100); // 中央にロゴ配置 api.multifactor.setQRCode(canvas.toDataURL('image/png')); } }; |
セキュリティ留意点：外部画像を読み込む際は、信頼できるホストからのみ取得し、サイズや MIME タイプを検証してください。
5‑2. Management API によるプログラム的操作
| 操作 | cURL 例 |
|---|---|
| プロバイダー一覧取得 | curl -H "Authorization: Bearer $MGMT_TOKEN" https://YOUR_DOMAIN/api/v2/multifactor/providers |
| ユーザーに OTP を付与 | curl -X PATCH -H "Content-Type: application/json" -d '{"multifactor":["otp"]}' https://YOUR_DOMAIN/api/v2/users/{user_id} |
| テナント全体の MFA ポリシー更新 | curl -X PATCH -d '{"mfa_policy":"conditional","allow_remember_browser":true}' https://YOUR_DOMAIN/api/v2/tenant/settings |
| ユーザーの MFA 状態取得 | curl -H "Authorization: Bearer $MGMT_TOKEN" https://YOUR_DOMAIN/api/v2/users/{user_id} |
ベストプラクティス：CI/CD パイプラインでトークンは 短命な機械アカウント から発行し、
$MGMT_TOKENはシークレット管理ツールで暗号化保存してください。
6. テスト・本番移行・監査・モニタリングのベストプラクティス
6‑1. テスト環境での検証フロー
ステージングテナントを作成し、実際のユーザーアカウントでエンドツーエンドの MFA フローを確認します。
- テナント複製：
Tenant Settings → Clone Tenantからコピーを作成 - テスト用電話番号・メールアドレスで SMS / OTP が正しく送信されるか検証
- Actions デバッグモードで
console.log出力を確認し、ロジックが期待通りに実行されていることを保証
最低でも「新規登録」「パスワードリセット」「IP 条件付き MFA」の 3 パターンは網羅してください。
6‑2. 本番導入時の留意点
| 項目 | 推奨対策 |
|---|---|
| レートリミット | SMS プロバイダー（例：Twilio）は秒間送信数に上限があるため、キューイング＋指数バックオフを実装 |
| バックアップコードの提供 | Enrollment 時に 10 個のリカバリーコードを生成し、PDF ダウンロードまたは暗号化保存リンクで配布 |
| 障害時のフェイルオーバー | プッシュ通知が利用不可の場合は自動的に OTP にフォールバックさせるロジック（Actions で判定） |
6‑3. ログストリームによる監査設定
- ダッシュボード → Logs → Log Streams → “Add Stream”
- 出力先として Splunk HEC、Datadog Logs、Amazon CloudWatch のいずれかを選択し、認証トークンを入力
- フィルタ条件で
type: "mfa"とevent（例：enrollment_success,challenge_failed）を指定
|
1 2 3 4 5 6 7 |
{ "filters": [ { "field": "type", "operator": "eq", "value": "mfa" }, { "field": "event", "operator": "in", "value": ["enrollment_success","challenge_failed"] } ] } |
この設定により、MFA に関する全イベントがリアルタイムで外部 SIEM に転送され、監査要件やインシデントレスポンスが容易になります。
7. 次のステップ
- 管理コンソールで MFA を有効化し、まずはテナント全体に基本的な保護を適用
- 開発環境で各認証要因（OTP・SMS・プッシュ・WebAuthn）を実装し、Actions と Management API によるカスタマイズを試す
- ステージングテナントで エンドツーエンドテスト を実施後、本番環境へ段階的にロールアウト
- ログストリームや SIEM 連携で 継続的なモニタリングと監査 を確立
最新情報は必ず公式ドキュメント（https://auth0.com/docs/ja-jp/secure/multi-factor-authentication）をご参照ください。実装中に疑問が生じた場合は Auth0 Community やサポートチームへ質問すると、迅速な回答が得られます。
本稿の内容は執筆時点（2024 年 5 月）の情報をもとに作成しています。将来の UI 改変や新機能追加については公式発表をご確認ください。