ユーザープールに MFA を追加します - Amazon Cognito
主要事項ユーザー MFA 設定MFA ロジックMFA を設定

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ユーザープールに MFA を追加します

これは、一般的にはユーザー名とパスワードになっている、初期設定の知っていることの認証要素に、持っていることの認証要素を追加するものです。パスワードを主要な認証要素とするユーザーをサインインさせるには、SMS テキストメッセージ、E メールメッセージ、または時間ベースのワンタイムパスワード (TOTP) を追加要素として選択できます。

多要素認証 (MFA) は、アプリケーション内のローカルユーザーのセキュリティを向上させます。フェデレーションユーザーの場合、Amazon Cognito はすべての認証プロセスを IdP に委任するので、追加の認証要素を提供しません。

注記

新しいユーザーがアプリに初めてサインインするときに、Amazon Cognito は OAuth 2.0 トークンを発行します。これは、ユーザープールに MFA が必要な場合でも同様です。ユーザーが初めてサインインするときの 2 番目の認証要因は、Amazon Cognito が送信する検証メッセージの確認です。ユーザープールに MFA が必要な場合、Amazon Cognito は、最初のログイン試行後の各サインイン試行で使用する追加のサインイン係数を登録するようユーザーに要求します。

アダプティブ認証では、リスクレベルの上昇に対応して、追加の要素認証を要求するようにユーザープールを設定できます。アダプティブ認証をユーザープールに追加するには、「脅威保護を備えた高度なセキュリティ」を参照してください。

ユーザープールの MFA が required に設定されている場合は、すべてのユーザーはサインインするために MFA を完了する必要があります。サインインするために、各ユーザーには、少なくとも 1 つの MFA 要素が必要です。MFA を必須にする場合は、ユーザーオンボーディングに MFA セットアップを含め、ユーザープールでユーザーのサインインを許可する必要があります。

MFA を必須に設定すると、マネージドログインは MFA を設定することをユーザーに求めます。ユーザープールで MFA をオプションとして設定すると、マネージドログインはユーザーに設定を求めません。オプションの MFA を使用するには、ユーザーに MFA を設定するかどうかを選択するようプロンプトを表示し、API 入力を案内して追加のサインイン要素を確認するインターフェースをアプリに構築する必要があります。

トピック

ユーザープールの MFA について知っておくべきこと

MFA を設定する前に、次の点を考慮します。

  • ユーザーは MFA を使用するか、またはパスワードなしの要素を使用してサインインできます。

    • ワンタイムパスワードまたはパスキーをサポートするユーザープールでは、MFA を必須に設定することはできません。

    • ユーザープールで MFA が必須である場合、WEB_AUTHN、EMAIL_OTP、または SMS_OTP を AllowedFirstAuthFactors に追加することはできません。Amazon Cognito コンソールでは、選択ベースのサインインのオプションを編集してパスワードなしの要素を含めることはできません。

    • 選択ベースのサインインでは、ユーザープールで MFA が必須である場合にのみ、すべてのアプリケーションクライアントに PASSWORD 要素と PASSWORD_SRP 要素を提供します。ユーザー名パスワードフローの詳細については、このガイドの「認証」章で「永続的なパスワードによるサインイン」と「永続的なパスワードと安全なペイロードによるサインイン」を参照してください。

    • MFA がオプションであるユーザープールでは、MFA 要素を設定したユーザーは、選択ベースのサインインでユーザー名パスワード認証フローを使用してのみサインインできます。これらのユーザーは、すべてのクライアントベースのサインインフローを利用できます。

    次の表は、ユーザープールの MFA 設定とユーザーによる MFA 要素の設定が、パスワードなしの要素を使用したユーザーのサインインに与える影響を示しています。

    ユーザープールの MFA 設定 ユーザーの MFA ステータス Webauthn/OTP が利用可能 パスワードによるサインイン後に MFA の設定を求められる WebAuthn/OTP でサインイン可能
    必須 Configured 不可 あり なし
    必須 未設定 不可 いいえ (サインインできない) 不可
    オプションです。 Configured WebAuthn は設定できるが、パスキーではサインインできない あり なし
    オプションです。 未設定 あり なし あり
    オフ いずれか あり なし あり

  • ユーザーが希望する MFA の方法は、パスワードの復旧に使用できる方法に影響します。希望する MFA を E メールメッセージにしたユーザーは、パスワードリセットコードを E メールで受信できません。希望する MFA を SMS メッセージにしたユーザーは、パスワードリセットコードを SMS で受信できません。

    希望するパスワードリセット方法の対象にユーザーがなっていない場合、[パスワード復旧] 設定で代替オプションを提供する必要があります。例えば、復旧メカニズムで E メールが最優先事項になっており、E メール MFA がユーザープールのオプションである場合があります。この場合、SMS メッセージによるアカウント復旧を 2 番目のオプションとして追加するか、管理 API オペレーションを使用してこれらのユーザーのパスワードをリセットします。

    Amazon Cognito は、有効な復旧方法を持たないユーザーからのパスワードリセットリクエストに対して、InvalidParameterException エラーレスポンスで応答します。

    UpdateUserPool のリクエスト本文の例は、AccountRecoverySetting を示しています。E メールメッセージによるパスワードのリセットが利用できない場合、ユーザーはここにフォールバックして、SMS メッセージによる復旧を行うことができます。

  • ユーザーは、MFA とパスワードのリセットコードを、同じ E メールアドレスや電話番号で受け取ることはできません。E メールメッセージのワンタイムパスワード (OTP) を MFA に使用する場合、アカウントの復旧には SMS メッセージを使用する必要があります。SMS メッセージの OTP を MFA に使用する場合、アカウントの復旧には E メールメッセージを使用する必要があります。MFA を使用するユーザープールでは、属性として E メールアドレスがあっても電話番号がないか、電話番号があっても E メールアドレスがない場合、ユーザーはセルフサービスのパスワード復旧を完了できない可能性があります。

    この設定でユーザーがユーザープールのパスワードをリセットできない状況を防ぐには、email および phone_number 属性を必須に設定します。別の方法として、ユーザーのサインアップ時や管理者によるユーザープロファイルの作成時に、これらの属性を常に収集して設定するようにプロセスを設定することもできます。ユーザーが両方の属性を持っている場合、Amazon Cognito は、ユーザーの MFA 要素ではない送信先にパスワードリセットコードを自動的に送信します。

  • ユーザープールで MFA を有効にし、2 番目の要素として SMS メッセージまたは E メールメッセージを選択すると、Amazon Cognito で検証していない電話番号または E メール属性にメッセージを送信できます。ユーザーが MFA を完了すると、Amazon Cognito は、phone_number_verified 属性または email_verified 属性を true に設定します。

  • MFA コードの提示に 5 回失敗すると、Amazon Cognito は サインイン試行の失敗時におけるロックアウト動作 で説明した指数関数的タイムアウトロックアウトプロセスを開始します。

  • アカウントがユーザープールの Amazon Simple Notification Service (Amazon SNS) リソース AWS リージョン を含む の SMS サンドボックスにある場合は、SMS メッセージを送信する前に Amazon SNS で電話番号を確認する必要があります。詳細については、「Amazon Cognito ユーザープール用の SMS メッセージ設定」を参照してください。

  • 脅威保護で検出されたイベントに応じてユーザーの MFA ステータスを変更するには、Amazon Cognito ユーザープールコンソールで MFA を有効にしてオプションとして設定します。詳細については、「脅威保護を備えた高度なセキュリティ」を参照してください。

  • E メールメッセージと SMS メッセージでは、各ユーザーに E メールアドレスと電話番号の属性が必要です。ユーザープールでは、email または phone_number を必須の属性として設定できます。この場合、ユーザーは電話番号を指定しない限りサインアップを完了できません。これらの属性について必要に応じた設定を行わずに、E メールメッセージ MFA または SMS メッセージ MFA を実行する場合は、サインアップ時に E メールアドレスまたは電話番号の入力を求めます。ベストプラクティスとして、ユーザープールを設定して、これらの属性を検証するようにユーザーに自動的にメッセージを送信します。

    Amazon Cognito は、ユーザーが SMS メッセージまたは E メールメッセージで仮コードを受信し、VerifyUserAttribute API リクエストでそのコードを返した場合、その電話番号または E メールアドレスを検証済みとしてカウントします。代わりに、チームは、電話番号を設定し、AdminUpdateUserAttributes API リクエストを実行する管理用アプリケーションを使用して検証済みとしてマークできます。

  • MFA を必須に設定し、複数の認証要素をアクティブ化した場合、Amazon Cognito は新しいユーザーに、使用する MFA 要素を選択するよう求めます。ユーザーは、SMS メッセージ MFA をセットアップするための電話番号と、E メールメッセージ MFA をセットアップするための E メールアドレスを持っている必要があります。使用可能なメッセージベースの MFA に属性が定義されていない場合、Amazon Cognito は TOTP MFA を設定するようにユーザーに求めます。MFA 要素 (SELECT_MFA_TYPE) を選択し、選択した要素 (MFA_SETUP) を設定するように求めるプロンプトが、InitiateAuth および AdminInitiateAuth の API オペレーションへのチャレンジレスポンスとして表示されます。

ユーザー MFA 設定

ユーザーは複数の MFA 要素を設定できます。アクティブにできるのは 1 つだけです。ユーザープール設定またはユーザープロンプトで、ユーザーの有効な MFA 設定を選択できます。ユーザープールの設定と独自のユーザーレベルの設定が以下の条件を満たす場合、ユーザープールは MFA コードをユーザーに要求します。

  1. ユーザープールで MFA をオプションまたは必須に設定している。

  2. ユーザーは、有効な email 属性または phone_number 属性を持っているか、Authenticator アプリケーションを TOTP 用にセットアップ済みである。

  3. 少なくとも 1 つの MFA 要素がアクティブである。

  4. 1 つの MFA 要素を優先として設定している。

サインインと MFA に同じ要素を使用しない

ユーザープールは、1 つのサインイン要素を、一部またはすべてのユーザーが使用できる唯一のサインインおよび MFA オプションにする方法で設定できます。この結果は、プライマリサインインのユースケースが E メールメッセージまたは SMS メッセージワンタイムパスワード (OTPs) である場合に発生する可能性があります。ユーザーの優先 MFA は、次の条件でサインインと同じタイプの要素になる場合があります。

  • ユーザープールには MFA が必要です。

  • E メールと SMS OTP は、ユーザープールでサインインオプションと MFA オプションを使用できます。

  • ユーザーは E メールまたは SMS メッセージ OTP でサインインします。

  • E メールアドレス属性はありますが、電話番号属性はありません。または、電話番号属性はありますが、E メールアドレス属性はありません。

このシナリオでは、ユーザーは E メール OTP でサインインし、E メール OTP で MFA を完了できます。このオプションは、MFA の必須関数をキャンセルします。ワンタイムパスワードでサインインするユーザーは、MFA とは異なる配信方法をサインインに使用できる必要があります。ユーザーに SMS と E メールの両方のオプションがある場合、Amazon Cognito は別の要素を自動的に割り当てます。たとえば、ユーザーが E メール OTP でサインインする場合、希望する MFA は SMS OTP です。

ユーザープールがサインインと MFA の両方で OTP 認証をサポートしている場合に、次の手順を実行して同要素認証に対処します。

  1. E メールと SMS OTP の両方をサインイン要因として有効にします。

  2. E メールと SMS OTP の両方を MFA 要因として有効にします。

  3. 収集

ユーザープールの設定と MFA オプションへの影響

ユーザープールの設定は、ユーザーが選択できる MFA の方法に影響します。以下のいくつかのユーザープール設定が、ユーザーによる MFA の設定に影響します。

  • Amazon Cognito コンソールの [サインイン] メニューの [多要素認証] 設定で、MFA をオプションまたは必須に設定するか、オフにすることができます。この設定と同等の API は、CreateUserPool、UpdateUserPool、および SetUserPoolMfaConfig の MfaConfiguration パラメータです。

    また、[多要素認証] 設定では、[MFA の方法] 設定によって、ユーザーが設定できる MFA 要素が決まります。この設定と同等の API は SetUserPoolMfaConfig オペレーションです。

  • [サインイン] メニューの [ユーザーアカウントの復旧] で、パスワードを忘れたユーザーにユーザープールからメッセージを送信する方法を設定できます。ユーザーの MFA の方法は、パスワードを忘れた場合のコードをユーザープールから配信する方法と同じにすることはできません。パスワードを忘れた場合の配信方法の API パラメータは、CreateUserPool および UpdateUserPool の AccountRecoverySetting パラメータです。

    例えば、復旧オプションが [E メールのみ] の場合、ユーザーは E メール MFA を設定できません。これは、同じユーザープールで E メール MFA を有効にして、復旧オプションを [E メールのみ] に設定することはできないためです。このオプションを [使用可能な場合は E メール、それ以外の場合は SMS] に設定すると、E メールが優先の復旧オプションになりますが、ユーザーが E メールメッセージ復旧の対象でない場合、ユーザープールは SMS メッセージにフォールバックできます。この場合、ユーザーは E メール MFA を優先として設定し、パスワードをリセットするときにのみ SMS メッセージを受信できます。

  • 使用できるものとして 1 つの MFA の方法のみを設定した場合、ユーザーの MFA 設定を管理する必要はありません。

  • SMS をアクティブに設定すると、ユーザープールで SMS メッセージが、使用できる MFA の方法に自動的になります。

    ユーザープール内の独自の Amazon SES リソースと、エッセンシャル機能プランまたはプラス機能プランを使用した、アクティブな E メール設定により、E メールメッセージは自動的にユーザープールで使用可能な MFA 方法になります。

  • ユーザープールで MFA を必須に設定すると、ユーザーは MFA の方法を有効または無効にできません。設定できるのは、希望する方法のみです。

  • ユーザープールで MFA をオプションとして設定すると、マネージドログインは、MFA を設定するようユーザーに求めません。ただし、希望する MFA の方法を持っているユーザーには、MFA コードの入力を求めます。

  • [脅威保護] を有効にし、アダプティブ認証レスポンスをフル機能モードで設定する場合、MFA がユーザープールでオプションになっている必要があります。アダプティブ認証によるレスポンスオプションの 1 つは、サインイン試行にリスクレベルが含まれていると評価されたユーザーに MFA を要求することです。

    コンソールの [サインアップ] メニューの [必須属性] 設定は、ユーザーがアプリケーションにサインアップするために E メールアドレスまたは電話番号を入力する必要があるかどうかを決定します。ユーザーが対応する属性を持っている場合、E メールメッセージと SMS メッセージは MFA 要素として適格になります。CreateUserPool のスキーマパラメータは、必要に応じて属性を設定します。

  • ユーザープールで MFA を必須として設定した場合、ユーザーがマネージドログインを使用してサインインすると、Amazon Cognito はユーザープールで利用可能な MFA 方法から選択するようユーザーに求めます。マネージドログインは、E メールアドレスまたは電話番号の収集と TOTP の設定を処理します。以下の図は、Amazon Cognito がユーザーに提示するオプションの背後のロジックを示しています。

ユーザーの MFA 設定を構成する

アクセストークン認証を使用するセルフサービスモデル、または管理 API オペレーションを使用する管理者管理モデルで、ユーザーの MFA の希望を設定できます。これらのオペレーションは MFA の方法を有効または無効にし、複数の方法のうちのいずれかを、希望するオプションとして設定します。ユーザーが MFA の希望を設定すると、Amazon Cognito はサインイン時に、希望する MFA の方法によるコードを提供するようにユーザーに求めます。希望を設定していないユーザーは、SELECT_MFA_TYPE チャレンジで、希望する方法を選択するよう求めるプロンプトを受け取ります。

  • ユーザーセルフサービスモデルまたはパブリックアプリケーションでは、サインインユーザーのアクセストークンで認可された SetUserMfaPreference によって MFA の設定が決まります。

  • 管理者管理アプリケーションまたは機密アプリケーションでは、管理者 AWS 認証情報で承認された AdminSetUserPreference が MFA 設定を設定します。

また、Amazon Cognito コンソールの [ユーザー] メニューからユーザーの MFA 設定を構成することもできます。Amazon Cognito ユーザープール API オペレーションのパブリック認証モデルと機密認証モデルの詳細については、「API、OIDC、マネージドログインページの認証についての理解」を参照してください。

ユーザー実行時の MFA ロジックの詳細

ユーザーがサインインするときに実行する手順を決定するために、ユーザープールはユーザーの MFA 設定、ユーザー属性、ユーザープールの MFA 設定、脅威保護アクション、セルフサービスのアカウントの復旧に関する設定を評価します。次に、ユーザーをサインインさせ、MFA の方法の選択、設定、または入力をユーザーに求めます。MFA の方法を設定する場合、ユーザーは E メールアドレスまたは電話番号を指定するか、TOTP Authenticator を登録する必要があります。事前に MFA のオプションを設定し、優先オプションを登録することもできます。以下の図は、ユーザープールの設定が、初回サインアップ直後のサインイン試行にどのような影響を及ぼすかを詳しく示しています。

ここに示したロジックは、SDK ベースのアプリケーションとマネージドログインのサインインに適用されますが、マネージドログインの場合、影響はあまり明確ではありません。MFA のトラブルシューティングを行うときは、ユーザーの結果から遡って、決定に影響を及ぼしたユーザープロファイルやユーザープールの設定を検討してください。

Amazon Cognito ユーザープールでのエンドユーザーによる MFA 選択の意思決定プロセスを示す図。

次のリストは、意思決定ロジック図の番号に対応したステップごとの詳しく説明です。 checkmark は、認証の成功とフローの結果を示します。 error は、認証の失敗を示します。

  1. ユーザーはサインイン画面でユーザー名を入力するか、ユーザー名とパスワードを入力します。有効な認証情報を提示しない場合、サインインリクエストは拒否されます。

  2. ユーザー名パスワード認証が成功したら、MFA を必須、オプション、またはオフのいずれにするかを決めます。オフにした場合は、正しいユーザー名とパスワードを入力すると、認証が成功します。 Green circular icon with a checkmark symbol inside.

    1. MFA をオプションにした場合は、ユーザーが TOTP Authenticator を設定済みであるかどうかを確認します。TOTP を設定済みである場合は、TOTP を使用した MFA を求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。 Green circular icon with a checkmark symbol inside.

    2. 脅威保護のアダプティブ認証機能により、MFA を設定することをユーザーに求めているかどうかを確認します。MFA が割り当てられていない場合、ユーザーはサインインされます。 Green circular icon with a checkmark symbol inside.

  3. MFA が必須であるか、アダプティブ認証が MFA を割り当て済みである場合は、ユーザーが MFA 要素を有効および優先として設定しているかどうかを確認します。設定している場合は、その要素を使用した MFA の入力を求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。 Green circular icon with a checkmark symbol inside.

  4. ユーザーが MFA 設定を指定していない場合は、ユーザーが TOTP Authenticator を登録済みであるかどうかを確認します。

    1. ユーザーが TOTP Authenticator を登録済みである場合は、TOTP MFA がユーザープールで使用可能かどうかを確認します (ユーザーが以前に Authenticator を設定した後で、TOTP MFA が無効になっている可能性があります)。

    2. E メールメッセージ MFA または SMS メッセージ MFA もユーザープールで利用できるかどうかを確認します。

    3. E メール MFA も SMS MFA も利用できない場合は、ユーザーに TOTP を使用した MFA を求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。 Green circular icon with a checkmark symbol inside.

    4. E メール MFA または SMS MFA が利用可能な場合は、ユーザーが対応する email 属性または phone_number 属性を持っているかどうかを確認します。持っている場合は、セルフサービスのアカウント復旧のプライマリ方法ではなく、MFA が有効になっている属性であれば、ユーザーが使用できます。

    5. TOTP と利用可能な SMS MFA 要素または E メール MFA 要素を含む MFAS_CAN_SELECT オプションを使用して、SELECT_MFA_TYPE チャレンジに応答するようユーザーに求めます。

    6. SELECT_MFA_TYPE チャレンジに応じて選択した要素の入力をユーザーに求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。 Green circular icon with a checkmark symbol inside.

  5. ユーザーが TOTP Authenticator を登録していないか、登録済みでも TOTP MFA が現在無効になっている場合は、ユーザーが email 属性または phone_number 属性を持っているかどうかを確認します。

  6. ユーザーが属性として E メールアドレスまたは電話番号のみを持っている場合、その属性が、ユーザープールでパスワードリセット用のアカウント復旧メッセージを送信するために実装する方法と同じであるかどうかを確認します。同じである場合、MFA を必須としているサインインは完了できず、Amazon Cognito はエラーを返します。このユーザーのサインインを有効にするには、復旧用ではない属性を追加するか、TOTP Authenticator を登録する必要があります。

    1. 復旧用ではない E メールアドレスや電話番号を利用できる場合は、対応する E メール要素または SMS MFA 要素が有効になっているかどうかを確認します。

    2. 復旧用ではない E メールアドレス属性があり、E メール MFA が有効になっている場合は、EMAIL_OTP チャレンジに応答するよう求められます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。 Green circular icon with a checkmark symbol inside.

    3. 復旧用ではない電話番号属性があり、SMS MFA が有効になっている場合は、SMS_MFA チャレンジに応答するよう求められます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。 Green circular icon with a checkmark symbol inside.

    4. 有効な E メール MFA 要素または SMS MFA 要素の対象となる属性がない場合は、TOTP MFA が有効になっているかどうかを確認します。TOTP MFA が無効になっている場合、ユーザーは MFA を必須としているサインインを完了できず、Amazon Cognito はエラーを返します。このユーザーのサインインを有効にするには、復旧用ではない属性を追加するか、TOTP Authenticator を登録する必要があります。

      注記

      ユーザーが TOTP Authenticator を持っているが TOTP MFA が無効になっている場合、このステップは [いいえ] と評価済みです。

    5. TOTP MFA が有効になっている場合は、MFAS_CAN_SETUP オプションの SOFTWARE_TOKEN_MFA を使用してユーザーに MFA_SETUP チャレンジを提示します。このチャレンジを完了するには、ユーザーの TOTP Authenticator を個別に登録し、"ChallengeName": "MFA_SETUP", "ChallengeResponses": {"USERNAME": "[username]", "SESSION": "[Session ID from VerifySoftwareToken]}" を使用して応答する必要があります。

    6. ユーザーが VerifySoftwareToken リクエストからのセッショントークンで MFA_SETUP チャレンジに応答すると、ユーザーは SOFTWARE_TOKEN_MFA チャレンジに応答するよう求められます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。 Green circular icon with a checkmark symbol inside.

  7. ユーザーが E メールアドレスと電話番号の両方を持っている場合は、どちらの属性がパスワードリセットのアカウント復旧メッセージのプライマリ方法であるかを確認します。

    1. セルフサービスのアカウントの復旧が無効になっている場合は、どちらの属性も MFA に使用できます。E メール MFA 要素と SMS MFA 要素の一方または両方が有効になっているかどうかを確認します。

    2. 両方の属性が MFA 要素として有効になっている場合は、MFAS_CAN_SELECT のオプション (SMS_MFA と EMAIL_OTP) を使用して SELECT_MFA_TYPE チャレンジに応答するようユーザーに求めます。

    3. SELECT_MFA_TYPE チャレンジに応じて選択した要素の入力をユーザーに求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。 Green circular icon with a checkmark symbol inside.

    4. 1 つの属性のみが適格な MFA 要素である場合は、残りの要素のチャレンジに応答するようユーザーに求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。 Green circular icon with a checkmark symbol inside.

      この結果が生じるのは、以下の場合です。

      1. ユーザーが email 属性と phone_number 属性を持っていて、SMS MFA と E メール MFA が有効であり、アカウント復旧のプライマリ方法が E メールまたは SMS メッセージである場合。

      2. ユーザーが email 属性と phone_number 属性を持っていて、SMS MFA または E メール MFA の一方のみが有効であり、セルフサービスのアカウントの復旧が無効になっている場合。

  8. ユーザーが TOTP Authenticator を登録しておらず、email 属性も phone_number 属性も持っていない場合は、MFA_SETUP チャレンジに応答するようユーザーに求めます。MFAS_CAN_SETUP のリストには、ユーザープールのすべての有効な MFA 要因のうち、アカウント復旧のプライマリ方法ではないものが表示されます。ユーザーは E メール MFA または TOTP MFA で ChallengeResponses を使用し、このチャレンジに応答できます。SMS MFA を設定するには、電話番号属性を別個に追加し、認証を再開します。

    TOTP MFA の場合は、"ChallengeName": "MFA_SETUP", "ChallengeResponses": {"USERNAME": "[username]", "SESSION": "[Session ID from VerifySoftwareToken]"} を使用して応答します。

    E メール MFA の場合は、"ChallengeName": "MFA_SETUP", "ChallengeResponses": {"USERNAME": "[username]", "email": "[user's email address]"} を使用して応答します。

    1. SELECT_MFA_TYPE チャレンジに応じて選択した要素の入力をユーザーに求めます。MFA チャレンジに正常に応答すると、ユーザーはサインインされます。 Green circular icon with a checkmark symbol inside.

ユーザープールでの多要素認証を設定する

MFA を設定するには、Amazon Cognito コンソールを使用するか、SetUserPoolMfaConfig API オペレーションと SDK メソッドを使用できます。

Amazon Cognito コンソールで MFA を設定する

  1. Amazon Cognito コンソールにサインインします。

  2. [User Pools] (ユーザープール) を選択します。

  3. リストから既存のユーザープールを選択するか、ユーザープールを作成します。

  4. [サインイン] メニューを選択します。[多要素認証] を見つけて、[編集] を選択します。

  5. ユーザープールで使用する [MFA enforcement] (MFA 強制実行) 方法を選択します。

    Amazon Cognito コンソールの MFA オプションを示すスクリーンショット。

    1. MFA が必要。ユーザープール内のすべてのユーザーは、さらに SMS、E メール、または時間ベースのワンタイムパスワード (TOTP) コードを追加の認証要素として使用し、サインインする必要があります。

    2. オプションの MFA。ユーザーに追加のサインイン要素を登録するオプションを提供した場合でも、MFA を設定していないユーザーに依然としてサインインを許可できます。アダプティブ認証を使用している場合は、このオプションを選択してください。アダプティブ認証の詳細については、「脅威保護を備えた高度なセキュリティ」を参照してください。

    3. MFA なし。ユーザーは、サインイン要素を追加登録することはできません。

  6. アプリケーションでサポートする [MFA methods] (MFA メソッド) を選択します。2 番目の要素として E メールメッセージ、SMS メッセージまたは TOTP 生成認証アプリケーションを設定できます。

  7. 2 番目の要素として SMS テキストメッセージを使用していて、SMS メッセージ用の Amazon Simple Notification Service で使用する IAM ロールを設定していない場合は、コンソールで作成できます。ユーザープールの [認証方法] メニューで、[SMS] を見つけて [編集] を選択します。Amazon Cognito がユーザーに SMS メッセージを送信することを許可する既存のロールを使用することもできます。詳細については、「IAM ロール」を参照してください。

    E メールメッセージを第 2 の要素として使用し、Amazon Simple Email Service (Amazon SES) で E メールメッセージに使用する送信元 ID を設定していない場合は、コンソールで作成します。[SES で E メールを送信] オプションを選択する必要があります。ユーザープールの [認証方法] メニューで、[E メール] を見つけて [編集] を選択します。リストの利用可能な検証済み ID から [送信元の Eメールアドレス] を選択します。検証済みドメイン (example.com など) を選択した場合は、検証済みドメイン (admin-noreply@example.com など) で [送信者の名前] も設定する必要があります。

  8. [Save changes] (変更の保存) をクリックします。