メインコンテンツへスキップ
Auth0は多要素認証（MFA）でユーザーアクセスを確保するための様々な要素をサポートしています。ポストログインアクションを使用することで、フローをカスタマイズし、指定要素でユーザーにに登録を促します。要素でユーザーが登録をした後、その要素を今後のログインの認証の2番目のメソッドとして使用できます。 コンテキスト情報を使用して、MFA登録フローをさらにカスタマイズすることもできます。たとえば、あるアプリケーションではSMSに登録するようユーザーに促し、別のアプリケーションではプッシュ通知またはWebAuthNに登録するようユーザーに促すことができます。 この機能を使用すると、MFA登録フローをカスタマイズすることができます。すでに登録されているユーザーのMFAフローをカスタマイズしたい場合、「ユニバーサルログインに対するMFA選択をカスタイズする」を参照してください。

​
仕組み

アクションを使用して、MFA登録フローをカスタマイズできます。具体的には、ログインフローのポストログイントリガーを、以下の認証APIメソッドを使用して変更できます：
  • enrollWith：登録時にユーザーに表示されるデフォルトの要素を指定します。オプションで、ユーザーが選択できる要素の代替リストを提供することも可能です。提供される場合、「別のメソッドを試す」リンクが登録プロンプトに表示されます。
  • enrollWithAny：登録時にユーザーが選択できる要素のセットを指定します。デフォルトでは、このメソッドは、ユーザーが希望する要素を選択できる選択プロンプトを表示します。場合によっては、ユーザーエクスペリエンスが異なる場合があります。
    • 複数の要素が指定された場合、選択プロンプトがユーザーに表示されます。
    • ユーザーが1つを除く他のすべての指定された要素で登録済みの場合は、選択プロンプトはスキップされ、ユーザーは残りのファクターで登録するように促されます。
    • ユーザーがすべての指定された要素で登録済みの場合は、コマンドは失敗し、ログインシーケンスは継続します。
これらのメソッドを組み合わせて、MFA登録フローをカスタマイズできます。ロールや最後にログインした日付などのユーザーメタデータを組み込んで、よりカスタマイズされたエクスペリエンスを作成することもできます。 カスタマイズされた登録フローは次の要素をサポートします。
  • otp
  • recovery-code
  • push-notification
  • phone
    • preferredMethod: voice
    • preferredMethod: sms
    • preferredMethod: both
  • webauthn-platform
  • webauthn-roaming
ユーザーが要素で登録した後、その値はenrolledFactorsに追加されます。このプロパティは、ユーザーアカウントに関連したアクティブ要素のリストを示します。 メソッド名がmfaに設定されている場合、配列event.authentication.methodsにはtypeフィールドが含まれます。このフィールドには、enrolledFactorsのtypeフィールドで使用されるものと一致する因子値（文字列）が含まれます。 MFA登録が発生すると、methods にはname:mfaのオブジェクトが含まれ、 typeがそのイベントに使用される要素に設定されます。methodsとenrolledFactorsはアクションが最初に開始されたときにのみ更新されます。フローの次のアクションで登録イベントの結果にアクセスできます。 詳しくは、以下のリソースをご確認ください:

​
シーケンス化されたフローとコンテキストに基づくフロー

enrollWithやenrollWithAnyコマンドを使用することで、コンテキスト情報を活用してユーザーに提示する最適な登録や一連の登録を決定できます。
  • enrollWithコマンドは、初期またはデフォルトの要素と代替のリストをサポートします。ユーザーはコマンドごとに1つの要素のみを登録できます。
  • enrollWithAnyコマンドは要素のリストをサポートします。指定された要素の順序によって、リストがユーザーにどのように表示されるかが決まります。ユーザーはコマンドごとに1つの要素のみを登録できます。
これらのコマンドを使用すると、次のことが可能になります。
  • シーケンス化されたフロー ：ユーザーに対して、特定の順序に並べた、一連の要素で登録します。
  • コンテキストに基づくフロー ：フロー内での以前のコマンドに基づいて、どの要素でユーザーに促すかを決定します。
これらのフローを説明するために、次の例を考えてみましょう: 
// Action 1

exports.onExecutePostLogin = async (event, api) => {
  if (event.user.enrolledFactors.length) {
    // already enrolled, challenge
    api.authentication.challengeWithAny(event.user.enrolledFactors.map(m => ({type: m.type})));
    if (event.user.app_metadata.isAdmin &&
        !event.user.enrolledFactors.some(m => m.type === 'webauthn-roaming')) {
          // if is admin and doesn't have a security key, meaning a different factor was used, enroll now
          api.authentication.enrollWith({type: 'webauthn-roaming'})
        }
  }
  else {
    // not enrolled; choose a factor to enroll now
    api.authentication.enrollWithAny([{type: 'webauthn-roaming'}, {type: 'otp'}]);
    if (event.user.app_metadata.isAdmin) {
      // one more factor for admins
      api.authentication.enrollWithAny([{type: 'webauthn-roaming'}, {type: 'otp'}]);
    }
  }
};

// Action 2

exports.onExecutePostLogin = async (event, api) => {
  function performed(type) {
    return event.authentication.methods.some(m => m.name === 'mfa' &&
           m.type === type &&
           Date.now() - new Date(m.timestamp).getTime() < 5000)
  }
  if (event.user.app_metadata.isAdmin) {
      // enforce both factors are used by challenging the one that has not been used yet
      if (!performed('webauthn-roaming')) {
        api.authentication.challengeWith({type: 'webauthn-roaming'})
      }
      else if (!performed('otp')) {
        api.authentication.challengeWith({type: 'otp'})
      }
  }
};
これら2つのアクションを組み合わせると、管理者ロールを持たない ユーザーがワンタイムパスワード（OTP）またはセキュリティ キーのいずれかを使用して登録する必要があるシナリオが作成されます。逆に、管理者ロールを持つ ユーザーは、両方の要素に登録する必要があります。 アクション1は、app_metadataを確認してユーザーが管理者であるかどうかを判断し、特定の要素に登録するようユーザーに促します。管理者ユーザーがOTPのみに登録している場合は、最初にOTPを入力して認証を完了する必要があります。次に、セキュリティキー（webauthn-roaming）を使用して登録するように促されます。
ユーザーアカウントの安全性を確保するため、認証要素を追加したいユーザーは、既存のenrolledFactorsの1つを使ってMFAチャレンジを完了しなければなりません。この条件があることで、異なる要素と構成を持つアプリケーションがすでに使用されている状況で、カスタムのMFA登録ポリシーを安全に実装することが可能になります。
アクション1の実行後、フローは一時停止し、アクション2の実行時にevent.user.enrolledFactorsとevent.authentication.methodsの両方が更新されます。これにより、ユーザーにさまざまな要素に異議を申し立てるか登録するかの選択肢が与えられたときに、アクションコードは実際のユーザーデータに基づいて決定を下すことができます。 注意 ：アクションを実行するこの方法は、enrollWithまたはenrollWithAnyコマンドを含むものにしか適用されません。その他の目的を果たすアクションに影響はありません。

​
開始する前に

MFAフローをカスタマイズする前に、テナントでMFAをセットアップし、アクション設定を使用して、MFA要素のカスタマイズを有効にします。［（Auth0ダッシュボード）］の［Security（セキュリティ）］>［Multi-factor Auth（多要素認証Auth）］から、1つ以上の要素を設定し、MFAポリシーを定義することができます。 フローのカスタマイズには、［追加設定］セクションのアクショントグルを使用して、［MFA要素のカスタマイズ］を有効にする必要があります。この設定が無効になっている場合、カスタマイズされたフローは、正常に作動しません。
［Auth0 Dashboard］>［Security（セキュリティ）］>［MFA（多要素認証）］>［Additional Settings（追加設定）］
注意 ：enrollWithまたはenrollWithAnyコマンドを使用したアクションは、テナントでMFAを有効または無効にする既存のポリシーまたはルールをオーバーライドします。

​
MFA登録フローをカスタマイズする

テナントにMFAを設定した跡、ログイン後のアクションを作成してMFA登録フローをカスタマイズできます。
1つのテナント内のアクション（または一連のアクション）は、1つのユーザーフローにつき、次の4つ のコマンドしか実行できません。
  • enrollWith
  • enrollWithAny
  • challengeWith
  • challengeWithAny
この制限を超えると（つまり、このタイプの5つ目のコマンドを実行しようとすると）、認証エラーが発生します。

​
ポストログインアクションを作成する

アクションをAuth0 Dashboardで作成できます。
  1. ［Actions（アクション）］>［Flows（フロー）］に移動し、［Login（ログイン）］ を選択します。
  2. 追加アクションパネルで、プラス記号(+) アイコンを選択し、［Build from scratch（ゼロから構築）］ を選択します。
  3. アクションの作成のポップアップでの表示:
    • アクションの名前を入力します。
    • トリガーとして、 ログイン/ポストログイン を選択します。
    • ランタイムには、Node 18（推奨） を使用します。
  4. 正確性のために、ポップアップをご確認ください。その後、 ［作成］ を選択します。
  5. コードエディターでは、カスタムコードをonPostExecuteコマンドに追加します。
  6. コマンドの準備が整ったら、［導入］ を選択します。
  7. 成功した導入通知で ［フローの追加］ を選択します。
    • 注意 ：通知が閉じられている場合、コードエディターの上の ［Back to Flow（フローに戻る）］ を選択します。
  8. 新しいコマンドを「アクションの追加」パネルから、ログインフローにドラッグアンドドロップします。その後、［適用］ を選択します。
保存後に追加の変更を行う場合、［Actions（アクション）］>［Library（ライブラリ）］>［Custom（カスタム）］に移動し、アクションを選択します。その後、必要な時にコードの更新と再導入ができます。

​
ポストログインアクションをテストする

コマンドが適切に機能するように、Auth0 Dashboardを通じてアクションをテストできます:
  1. ［認証］>［認証プロファイル］に移動します。
  2. ［試す］ を選択し、新しいタブでログインプロンプトのサンプルを開きます。
  3. 資格情報を入力し、新しいMFAフローをテストします。
フローが成功したら、確認画面が表示されます。問題が生じたら,、Auth0 Dashboardの［Actions（アクション）］>［Library（ライブラリ）］>［Custom（カスタム）］に移動し、コードを更新することができます。

​
ユースケースの例

以下の例では、MFA登録フローをカスタマイズする際の一般的なユースケースを示しています。

​
登録に対してMFAオプションでユーザーを促す

次のサンプルでは、デフォルトで、OTPでユーザーにチャレンジを行います。必要であれば、ユーザーは「他の方法を試す」リンクにアクセスし、代わりにメールで認証することができます。

​
トラブルシューティング

カスタマイズされたMFA登録でエラーや予期しない結果が発生した場合は、以下の情報を使用して問題を特定し解決するのに役立ててください。

​
テナントログ

テナントログを通じて、カスタマイズされたMFA登録を監視できます。 テナントログは、Auth0 Dashboardの［Monitoring（モニタリング）］>［Logs（ログ）］から利用可能です。その他に、Management APIを使用して、ログを取得します。 予期しない動作が発生した場合は、次のイベントコードのテナントログを確認して、詳細情報を得てください。
シナリオイベントエラーメッセージ
ユーザーが特定の要素で登録することを促されます。 ところが、要求された要素は以下の1つの条件に該当しています。
  • 要素がテナントで有効化されていない。
  • ユーザーのブラウザーが要素に対応していない。
  • ユーザーがすでに要求された要素で登録している。
この場合、他の要素を代わりに使用できるのであれば、ユーザーはフローを完了させることができます。		wPostLoginアクションではMFAの登録が使用されたものの、要求された要素である${factor.name}が適切にセットアップされていません。要求された要素を有効化し、ユーザーがそれを使ってすでに登録していないことを確認します。
ユーザーは1つ以上の要素で登録することを促されたものの、指定された要素が登録に使用できません。この場合、ユーザーはフローを完了できません。mfarPostLoginアクションではMFAの登録が使用されたものの、要求された要素が適切にセットアップされていません。MFAを実行するには、要求された要素を有効化し、ユーザーがそれらを使ってすでに登録していないことを確認します。
ユーザーが既存の登録で少なくとも1つのチャレンジを完了させることなく、新しい要素で登録しようとしています。mfarMFAの登録が要求されましたが、ユーザーはすでにMFAに登録しています。新しい要素で登録する前に、少なくとも1つの既存の要素でチャレンジします。

​
トラブルシューティングのチェックリスト

以下のチェックリストは、カスタマイズされたMFAフローに関する一般的な問題を特定し解決するための追加の提案を提供します。
  1. 「アクションでMFA要素をカスタマイズする」 トグルを有効にする必要があります。
  2. アクションで参照されるファクターは、テナントで有効にする必要があります。
  3. アクションが導入され、パイプラインに保存されていることを確認してください。
    1. ［Auth0 Dashboard（Auth0ダッシュボード）］>［Actions（アクション）］>［Library（ライブラリ）］>［Custom（カスタム）］に移動します。リストからアクションを見つけ、ステータスが 「導入済み」 になっていることを確認してください。異なるステータスが表示 されている場合、アクションにアクセスし、コードを確認したのち,右上の ［導入］ をクリックします。
    2. ［Auth0 Dashboard（Auth0ダッシュボード）］>［Actions（アクション）］>［Library（ライブラリ）］>［Flows（フロー）］に移動し、 ［ログイン］ を選択します。アクションがフローに表示されていることを確認してください。表示されていない場合、［アクションの追加］パネルの ［カスタム］タブ にアクセスし、ログインフローにアクションをドラッグアンドドロップします。その後、［適用］ を選択します。
  4. ポストログインアクションが最新バージョンにアップグレードされていることを確認してください。
⌘I