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

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

Adaptive MFA のカスタマイズを検討するのは、ユーザーが MFA に登録済みであり、識別子としてメールアドレスの使用が必須である場合に限ってください。
ユーザーが に登録されていない場合は、Adaptive MFA のデフォルトポリシーを使用してください。ユーザーが MFA に登録されておらず、かつ Action で高リスクと判定された場合、 を阻止するために取れる手段は限られます。 Adaptive MFA のカスタマイズを始める前に、次の点を確認してください。
  • どの信頼度レベルで MFA をトリガーしたいですか。
  • リスクをどのように測定したいですか。
  • 信頼度は Auth0 に測定させたいですか、それとも独自に測定したいですか。
  • MFA に登録していないユーザーをどのように扱いますか。

信頼度スコア

Adaptive MFA は、NewDeviceImpossibleTravelUntrustedIP の 3 つの評価の分析に基づいて、総合的な信頼度スコアを算出します。詳しくは、Adaptive MFA: 仕組みを参照してください。 各評価にはそれぞれ固有の信頼度スコアがあり、各信頼度スコアに対応するアクションがあります。
次の表は、low の信頼度スコアになる高リスク シナリオを示しています。次の表は、high の信頼度スコアになる低リスク シナリオを示しています。
さまざまなシナリオにおける総合的な信頼度スコアを評価する独自の方法を実装する場合は、総合的な信頼度スコア、バージョン情報、および個々の評価の詳細を含む riskAssessment オブジェクトで利用可能なデータを使用できます。 riskAssessment オブジェクトの完全な説明、プロパティ、および値は、post-login Actions trigger riskAssessment referenceで確認できます。

Action の結果

MFA をトリガーする Actions は、既定の Adaptive MFA の動作よりも優先されます。
いずれかの Actions が信頼度スコアに基づいて MFA をトリガーする場合、既定の Adaptive MFA ポリシーでは、信頼度スコアが low のときに MFA がトリガーされます。 次の表は、Actions と既定の Adaptive MFA ポリシーのアクションの組み合わせに応じた結果を示しています。

Action テンプレート

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

Adaptive MFA テンプレート

このテンプレートは、個別のリスク評価を使用してカスタムのビジネスフローを構築する方法の例と、その出発点を示します。この例では、次を使用します。
  • ログインフローの最後に、登録の処理と設定済みの MFA チャレンジの要求の両方を行う api.multifactor.enable Action トリガー。
  • ユーザーに登録済みの認証要素を含む event.user.multifactor Actions トリガー。
email 通知は独立した認証要素ではないため、ユーザーの認証要素が email のみである場合、条件 event.user.multifactor && event.user.multifactor.length > 0false を返します。詳細については、Configure Email Notifications for MFA を参照してください。
ユーザーに求めるには、api.multifactor.enableapi.authentication.challengeWithAny() に置き換えて、ユーザーがすでに登録している既存の認証要素で MFA チャレンジを強制します。Actions でサポートされている認証要素を確認するには、factors パラメーター を参照してください。例:
この例では、登録状況を確認するために event.user.multifactor ではなく event.user.enrolledFactors を使用しています。event.user.multifactor とは異なり、event.user.enrolledFactors には email も認証要素として含まれるため、メールアドレスのみを設定しているユーザーについても、登録済みの認証要素を正しく返します。

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

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

Action のユースケース

ユースケースに応じてカスタム Actions を構築する方法の例をいくつか紹介します。
riskAssessment.confidence プロパティを確認し、highmediumlow の定数と比較します。
信頼度スコアは範囲ではなく離散値であるため、比較演算子 (<> など) を使って、1 つの条件で複数の値を評価することはできません。処理したい信頼度スコアを論理的に組み合わせるには、複数の条件を使用します。たとえば、信頼度スコアが low より高い場合を判定したいなら、medium または high と等しいかどうかを確認します。
riskAssessment オブジェクトはテナントのログに保存されます。ログエントリを確認すると、リスク評価スコアとその判定要因 (理由) を確認できます。また、riskAssessment オブジェクトを参照して、その結果を別の場所に出力することもできます。たとえば、メールを送信したり、外部データベースにレコードを保存したりできます。
assessments オブジェクトを使用して、code プロパティを含む各評価の詳細にアクセスします。
assessments オブジェクトを使用して各評価の詳細にアクセスし、confidence プロパティ、code プロパティ、またはその両方を使用します。
assessments オブジェクトを使用して、code プロパティを含む各評価の詳細にアクセスします。UnauthorizedError オブジェクトを error パラメーターとして指定してコールバック関数を返すことで、ログインのトランザクションが完了しないようにブロックします。UnauthorizedError オブジェクトでは error は常に unauthorized に設定されますが、error_message はカスタマイズできます。
これにより、errorerror_message パラメーターを含めて、ユーザーはアプリケーションのコールバックURLにリダイレクトされます。
Auth0 は、リスク評価の実行中に何らかの障害が発生した場合、自動的に low の信頼度スコアを割り当てます。このシナリオを軽減するには、assessments オブジェクトを使用して各評価の code プロパティを確認し、値が assessment_not_available に設定されているかどうかを調べます。

詳細はこちら