メインコンテンツまでスキップ

多要素認証（MFA）

idp-serverにおける多要素認証（MFA）の管理と制御について説明します。

idp-serverでサポートするMFA手段​

MFA手段種類特徴制約
パスワード知識要素基本的な認証方式なし
Email OTP所持要素メールで送信されるワンタイムコードなし
SMS OTP所持要素SMSで送信されるワンタイムコード外部サービス連携必須
FIDO2/WebAuthn所持要素 + 生体要素セキュリティキー、指紋・顔認証事前認証必須、ACRポリシー適用可
FIDO-UAF所持要素 + 生体要素モバイルデバイス + 生体認証事前認証必須、ACRポリシー適用可

OTP送信方式​

Email OTPとSMS OTPでは、選択できる送信方式が異なります。

送信方式Email OTPSMS OTP説明
SMTP（内蔵）○-idp-server内蔵のSMTP送信機能。外部サービス不要
外部API委譲（http_request）○○OTPの生成・送信・検証を外部サービス（SendGrid、Twilio等）に委譲
no_action（開発用）○○OTPを内部生成するが送信しない。Management APIでコードを取得して検証
  • Email OTP: SMTP設定を行えばidp-server単体でメール送信が完結します。外部APIへの委譲も可能です
  • SMS OTP: SMS送信機能を内蔵していないため、本番環境では外部SMS送信サービスへのhttp_request委譲が必須です

MFA登録のタイミング​

idp-serverでは、以下のタイミングでMFA手段を登録できます。

1. 初回ログイン時​

新規ユーザーが初めてログインする際にMFA手段の登録を促します。

2. ログイン後の設定画面​

ユーザーがログイン後、任意のタイミングでMFA手段を追加・削除できます。

3. 認証フロー中​

認証ポリシーによりMFAが要求された際、まだ登録していない場合は認証フロー中に登録を促します。

認証ポリシーとの連携​

MFAは認証ポリシーと連携して動作します。

適用条件によるMFA要求​

認証ポリシーの適用条件に応じて、MFAを動的に要求します：

  • スコープベース: 機密スコープ（verified_claims）にはMFA必須
  • ACRベース: 特定のACR値（urn:mace:incommon:iap:gold）にはMFA必須
  • クライアントベース: モバイルアプリには生体認証を優先

ステップアップ認証​

既にログイン済みのユーザーに対して、操作の重要度に応じて追加のMFA認証を要求します。

シナリオ例:

  1. ユーザーがパスワードでログイン（通常操作可能）
  2. 送金操作を試みる
  3. システムが追加でFIDO2認証を要求
  4. FIDO2認証成功後、送金可能になる

ユーザー解決ロジック（Email/SMS OTP）​

Email OTPおよびSMS OTP認証では、以下のロジックでユーザーを解決します。

1要素目として使用する場合​

以下の優先順位でユーザーを解決します：

  1. データベース検索: 入力されたメールアドレス/電話番号でユーザーを検索
  2. トランザクション内ユーザーの再利用: 同一のメールアドレス/電話番号を持つユーザーがトランザクション内に存在する場合は再利用
  3. 新規ユーザー作成: allowRegistration=trueの場合のみ、新規ユーザーを作成

2要素目として使用する場合（requiresUser=true）​

認証済みユーザーが必須です。未認証の場合はエラーになります。

  1. 認証済みユーザーの確認: トランザクション内に認証済みユーザーが存在することを確認
  2. メールアドレス/電話番号の処理:
    • allowRegistration=true: 入力されたメールアドレス/電話番号で認証済みユーザーの情報を更新
    • allowRegistration=false: 認証済みユーザーに登録済みのメールアドレス/電話番号でのみ認証可能
  3. 認証コード送信: 対象のメールアドレス/電話番号にワンタイムコードを送信

制御パラメータ​

パラメータ説明
allowRegistration新規ユーザー登録またはメールアドレス/電話番号の更新を許可
requiresUser認証済みユーザーを必須とする（2要素目として使用）

MFAの評価​

認証ポリシーは、MFAの成功条件を定義します。

OR条件​

いずれかの認証方式が成功すれば認証完了。

  • パスワード認証 または FIDO2認証

AND条件（多要素認証）​

複数の認証方式すべてが成功して初めて認証完了。

  • パスワード認証 かつ SMS認証

認証デバイス登録のセキュリティ制約​

FIDO2/WebAuthnやFIDO-UAFなどの認証デバイス登録には、セキュリティ上の制約があります。

事前認証の必須要件​

認証デバイスの登録には、事前にユーザー認証が完了している必要があります。これにより、未認証の攻撃者が勝手にデバイスを登録することを防ぎます。

この制約により、FIDO2/FIDO-UAFデバイスのみでユーザー登録（パスワードレスオンボーディング）を完結することはできません。ユーザーは最初にパスワード認証やEmail認証など、他の認証方式で認証を行う必要があります。

デバイス登録時のACRポリシー​

認証ポリシーを設定することで、デバイス登録に必要な認証レベル（ACR）を強制できます。

例えば以下のようなポリシーを適用できます：

  • 新規デバイス登録時: Email認証や既存のFIDOデバイス認証を必須にする
  • 追加デバイス登録時: 既存の認証デバイスで認証してから登録可能にする

これにより、パスワードのみで認証したユーザーが新しいFIDOデバイスを登録することを防ぎ、アカウント乗っ取り後の不正デバイス登録リスクを軽減します。

エラーの種類​

状況エラー意味
ユーザーが未認証unauthorized認証が必要
ACRポリシー不足forbidden追加の認証が必要

セキュリティ考慮事項​

MFA手段のバックアップ​

主要なMFA手段が使えなくなった場合に備えて、バックアップ手段の登録を推奨します。

フィッシング耐性​

FIDO2/WebAuthnは、フィッシング攻撃に対して耐性があります。SMSやEmailのOTPは、フィッシングのリスクがあるため、重要な操作にはFIDO2を推奨します。

関連ドキュメント​

参考仕様​