Adaptive MFA をカスタマイズする

Adaptive Multi-Factor Authentication（MFA）をカスタマイズする方法を説明します。

Auth0 Actions を使用すると、さまざまなシナリオに応じて Adaptive MFA をカスタマイズできます。

​

Adaptive MFA をカスタマイズする場合

Adaptive MFA のカスタマイズを検討するのは、ユーザーが MFA に登録済みであり、識別子としてメールアドレスの使用が必須である場合に限ってください。

ユーザーが MFA に登録されていない場合は、Adaptive MFA のデフォルトポリシーを使用してください。ユーザーが MFA に登録されておらず、かつ Action で高リスクと判定された場合、悪意のある攻撃者 を阻止するために取れる手段は限られます。

Adaptive MFA のカスタマイズを始める前に、次の点を確認してください。

• どの信頼度レベルで MFA をトリガーしたいですか。
• リスクをどのように測定したいですか。
• 信頼度は Auth0 に測定させたいですか、それとも独自に測定したいですか。
• MFA に登録していないユーザーをどのように扱いますか。

​

信頼度スコア

Adaptive MFA は、NewDevice、ImpossibleTravel、UntrustedIP の 3 つの評価の分析に基づいて、総合的な信頼度スコアを算出します。詳しくは、Adaptive MFA: 仕組みを参照してください。

各評価にはそれぞれ固有の信頼度スコアがあり、各信頼度スコアに対応するアクションがあります。

Confidence score	Description	Action
low	ログイン トランザクションが、これまでのユーザーのパターンと一致しません。	MFA を要求します。
medium	ログイン トランザクションが、これまでのユーザーのパターンとある程度一致します。	MFA は要求しません。
high	ログイン トランザクションが、これまでのユーザーのパターンとほぼ一致します。	MFA は要求しません。
neutral	該当なし。将来の利用のために予約されています。	該当なし。将来の利用のために予約されています。

信頼度スコアごとの高リスクおよび低リスクのシナリオ例を表示

次の表は、low の信頼度スコアになる高リスク シナリオを示しています。

User State	Desired Login Friction	Desired Enrollment Policy	Implementation
MFA に登録済み	MFA を要求しない	該当なし (ユーザーはすでに登録済み)	Action を使用して MFA をバイパスする
MFA に未登録	メールアドレスの確認を要求する	登録をスキップする (追加の認証要素を収集しない)	デフォルトの動作 (MFA 関連の Action なし)
MFA に未登録	メールアドレスの確認を要求する	MFA 登録を要求する (追加の認証要素を収集する)	Action を使用して MFA 登録を強制する (テンプレートあり)

次の表は、high の信頼度スコアになる低リスク シナリオを示しています。

User State	Desired Login Friction	Desired Enrollment Policy	Implementation
MFA に登録済み	追加の手間なし	該当なし (ユーザーはすでに登録済み)	デフォルトの動作 (MFA 関連の Action なし)
MFA に未登録	追加の手間なし	登録をスキップする (追加の認証要素を収集しない)	デフォルトの動作 (MFA 関連の Action なし)
MFA に未登録	追加の手間なし	MFA 登録を要求する (追加の認証要素を収集する)	Action を使用して MFA 登録を強制する (テンプレートあり)

さまざまなシナリオにおける総合的な信頼度スコアを評価する独自の方法を実装する場合は、総合的な信頼度スコア、バージョン情報、および個々の評価の詳細を含む riskAssessment オブジェクトで利用可能なデータを使用できます。

riskAssessment オブジェクトの完全な説明、プロパティ、および値は、post-login Actions trigger riskAssessment referenceで確認できます。

​

Action の結果

MFA をトリガーする Actions は、既定の Adaptive MFA の動作よりも優先されます。

いずれかの Actions が信頼度スコアに基づいて MFA をトリガーする場合、既定の Adaptive MFA ポリシーでは、信頼度スコアが low のときに MFA がトリガーされます。

次の表は、Actions と既定の Adaptive MFA ポリシーのアクションの組み合わせに応じた結果を示しています。

Action の結果	Adaptive MFA のアクション	結果
未承認	MFA をトリガー	未承認
未承認	MFA は不要	未承認
MFA をトリガー	MFA をトリガー	MFA をトリガー
MFA をトリガー	MFA は不要	MFA をトリガー
MFA は不要	MFA をトリガー	MFA をトリガー
MFA は不要	MFA は不要	MFA は不要

​

Action テンプレート

Auth0 では、カスタマイズ可能な Adaptive MFA 用の Action テンプレートとして、Adaptive MFA と MFA 登録を必須にする の 2 つが提供されています。

​

Adaptive MFA テンプレート

このテンプレートは、個別のリスク評価を使用してカスタムのビジネスフローを構築する方法の例と、その出発点を示します。この例では、次を使用します。

• ログインフローの最後に、登録の処理と設定済みの MFA チャレンジの要求の両方を行う api.multifactor.enable Action トリガー。
• ユーザーに登録済みの認証要素を含む event.user.multifactor Actions トリガー。

email 通知は独立した認証要素ではないため、ユーザーの認証要素が email のみである場合、条件 event.user.multifactor && event.user.multifactor.length > 0 は false を返します。詳細については、Configure Email Notifications for MFA を参照してください。

/**
* PostLoginフローの実行中に呼び出されるハンドラー。
*
* @param {Event} event - ユーザーおよびログインコンテキストの詳細。
* @param {PostLoginAPI} api - ログインの動作を変更するために使用できるメソッドのインターフェース。
*/
exports.onExecutePostLogin = async (event, api) => {
    // MFAをトリガーする信頼度スコアを決定します。詳細については以下を参照してください。
    const promptConfidences = ['low', 'medium'];

    // 条件の例: NewDeviceの信頼レベルのみに基づいてMFAを要求します。
    // これにより、未知のデバイスからログインしたユーザーに対して
    // MFAが要求されます。
    const confidence =
        event.authentication?.riskAssessment?.assessments?.NewDevice
            ?.confidence;
    const shouldPromptMfa =
        confidence && promptConfidences.includes(confidence);

    // MFAを要求するのは、ユーザーが少なくとも1つのMFA認証要素を
    // 登録している場合に限ります。
    const canPromptMfa =
        event.user.multifactor && event.user.multifactor.length > 0;
    if (shouldPromptMfa && canPromptMfa) {
        api.multifactor.enable('any', { allowRememberBrowser: true });
    }
};

ユーザーに求めるには、api.multifactor.enable を api.authentication.challengeWithAny() に置き換えて、ユーザーがすでに登録している既存の認証要素で MFA チャレンジを強制します。Actions でサポートされている認証要素を確認するには、factors パラメーター を参照してください。例:

この例では、登録状況を確認するために event.user.multifactor ではなく event.user.enrolledFactors を使用しています。event.user.multifactor とは異なり、event.user.enrolledFactors には email も認証要素として含まれるため、メールアドレスのみを設定しているユーザーについても、登録済みの認証要素を正しく返します。

// MFAを要求するのは、ユーザーに少なくとも1つのMFA認証要素が登録されている場合のみ有効です。
const canPromptMfa = event.user.enrolledFactors && event.user.enrolledFactors.length > 0;

if (shouldPromptMfa && canPromptMfa) {
    api.authentication.challengeWithAny([ {type: "email"}, {type:"phone"} ]);
}

​

MFA 登録を必須にするテンプレート

このテンプレートは、標準または Adaptive MFA ポリシーの使用時に MFA 登録を必須にする方法を示しています。event.user.multifactor を使用してユーザーが MFA に登録済みかどうかを確認し、未登録の場合は登録を促します。

/**
* PostLogin フローの実行中に呼び出されるハンドラー。
*
* @param {Event} event - ユーザーおよびログイン時のコンテキストの詳細。
* @param {PostLoginAPI} api - ログインの動作を変更するために使用できるメソッドを持つインターフェース。
*/
exports.onExecutePostLogin = async (event, api) => {
    if (!event.user.multifactor?.length) {
        api.multifactor.enable('any', { allowRememberBrowser: false });
    }
};

​

Action のユースケース

ユースケースに応じてカスタム Actions を作成する際のヒントをいくつか紹介します。

総合信頼度スコアが X の場合にアクションを実行する

riskAssessment.confidence プロパティを確認し、high、medium、low の定数と比較します。

exports.onExecutePostLogin = async (event, api) => {
  const { riskAssessment } = event.authentication || {};
  const riskIsMedium = riskAssessment && riskAssessment.confidence === 'medium';

  if (riskIsMedium) {
    // ....
  }
}

信頼度スコアが X を上回るまたは下回る場合にアクションを実行する

信頼度スコアは範囲ではなく離散値であるため、比較演算子 (< や > など) を使って、1 つの条件で複数の値を評価することはできません。

処理したい信頼度スコアを論理的に組み合わせるには、複数の条件を使用します。たとえば、信頼度スコアが low より高い場合を判定したいなら、medium または high と等しいかどうかを確認します。

exports.onExecutePostLogin = async (event, api) => {
  const { riskAssessment } = event.authentication || {};
  const riskIsMediumOrHigh = riskAssessment && 
                                  (riskAssessment.confidence === 'high' || 
                                   riskAssessment.confidence === 'medium');

  if (riskIsMediumOrHigh) {
    // ...
  }
}

総合信頼度スコアが X の場合に追加の詳細を取得する

riskAssessment オブジェクトはテナントのログに保存されます。ログエントリを確認すると、リスク評価スコアとその判定要因 (理由) を確認できます。

また、riskAssessment オブジェクトを参照して、その結果を別の場所に出力することもできます。たとえば、メールを送信したり、外部データベースにレコードを保存したりできます。

exports.onExecutePostLogin = async (event, api) => {
  const { riskAssessment } = event.authentication || {};
  const riskIsLow = riskAssessment && riskAssessment.confidence === 'low';

  if (riskIsLow) {
    // log(externalDatabase, riskAssessment);
  }
}

特定の評価で特定の結果が返された場合にアクションを実行する

assessments オブジェクトを使用して、code プロパティを含む各評価の詳細にアクセスします。

exports.onExecutePostLogin = async (event, api) => {
  const { riskAssessment } = event.authentication || {};
  const { ImpossibleTravel } = riskAssessment && riskAssessment.assessments;

  if (ImpossibleTravel.code === 'impossible_travel_from_last_login') {
    // ...
  }
}

カスタムの総合信頼度スコアのために評価を集約する

assessments オブジェクトを使用して各評価の詳細にアクセスし、confidence プロパティ、code プロパティ、またはその両方を使用します。

特定の評価で特定の結果が返された場合に、現在のトランザクションをブロックしてエラーとメッセージを返す

assessments オブジェクトを使用して、code プロパティを含む各評価の詳細にアクセスします。

[UnauthorizedError オブジェクトを error パラメーター として指定してコールバック関数を返すことで、ログインのトランザクションが完了しないようにブロックします。UnauthorizedError オブジェクトでは error は常に unauthorized に設定されますが、error_message はカスタマイズできます。

exports.onExecutePostLogin = async (event, api) => {
  const { riskAssessment } = event.authentication || {};
  const { ImpossibleTravel } = riskAssessment && riskAssessment.assessments;

  if (ImpossibleTravel.code === 'impossible_travel_from_last_login') {
    return api.access.deny('Login blocked due to impossible travel detected.')
  }
}

これにより、error と error_message パラメーターを含めて、ユーザーはアプリケーションのコールバック URL にリダイレクトされます。

Auth0 が評価を実行できなかった場合も安全に処理する

Auth0 は、リスク評価の実行中に何らかの障害が発生した場合、自動的に low の信頼度スコアを割り当てます。

このシナリオを軽減するには、assessments オブジェクトを使用して各評価の code プロパティを確認し、値が assessment_not_available に設定されているかどうかを調べます。

​

詳細はこちら

• Adaptive MFAを有効にする
• Adaptive MFA のログイベント
• Actions トリガー: post-login - API オブジェクト
• Actions トリガー: post-login - Event オブジェクト