ユーザーアカウントのサインアップと確認

ユーザーアカウントは次の方法の 1 つでユーザープールに追加されます。

• ユーザーは、ユーザープールのクライアントアプリにサインアップします。これはモバイルまたはウェブアプリです。

• ユーザープールにユーザーのアカウントをインポートできます。詳細については、「CSV ファイルからユーザープールへのユーザーのインポート」を参照してください。

• ユーザープールにユーザーのアカウントを作成し、サインインへユーザーを招待することができます。詳細については、「管理者としてのユーザーアカウントの作成」を参照してください。

サインアップするユーザーは、サインインする前に確認が求められます。インポートされ作成されたユーザーはすでに確認されていますが、初めてサインインするときはパスワードを作成する必要があります。以下のセクションで、確認プロセス、E メール、電話確認について説明します。

ユーザーアカウント確認の概要

次の図は確認プロセスを示しています。

ユーザーアカウントは、以下のいずれかの状態になります。

登録済み (未確認)

ユーザーは正常にサインアップできますが、ユーザーアカウントを確認するまではサインインできません。ユーザーは有効ですが、この状態で確認されていません。

サインアップする新しいユーザーはこの状態から開始します。

確認済み

ユーザーアカウントが確認され、ユーザーはサインインできます。ユーザーがユーザーアカウントを確認するためにコードを入力したり、E メールのリンクをたどったりすると、その E メールや電話番号が自動的に認証されます。コードまたはリンクは 24 時間有効です。

ユーザーアカウントが管理者またはサインアップ前の Lambda トリガーによって確認された場合は、検証済みの E メールまたは電話番号がアカウントに関連付けられていないことがあります。

パスワードのリセットが必要

ユーザーアカウントは確認されましたが、ユーザーはサインインする前にコードをリクエストし、自身のパスワードをリセットする必要があります。

管理者またはデベロッパーがインポートしたユーザーアカウントは、この状態から開始します。

パスワードの強制変更

ユーザーアカウントが確認され、ユーザーは一時パスワードを使用してサインインできますが、初回のサインイン時に他の操作を行う前にパスワードを新しい値に変更する必要があります。

管理者またはデベロッパーが作成したユーザーアカウントは、この状態から開始します。

Disabled

ユーザーアカウントを削除する前に、そのユーザーのサインインアクセスを無効にする必要があります。

サインアップ時に連絡先情報を検証する

新しいユーザーがアプリにサインアップする際、1 つ以上の連絡先の入力を求める必要があります。たとえば、ユーザーの連絡先情報は、以下のように使用されます。

• ユーザーが自分のパスワードをリセットする際、仮パスワードを送信する。

• ユーザーの個人情報または財務情報が更新された際に通知する。

• プロモーションメッセージ (特価販売や割引など) を送信する。

• アカウントの概要または請求日のお知らせを送信する。

このようなユースケースでは、検証済みの送信先にメッセージを送信することが重要です。そうしないと、誤入力された無効な E メールアドレスまたは電話番号にメッセージが送信される可能性があります。さらに悪いケースでは、ユーザーを騙る悪人に機密情報が送信される可能性があります。

適切なユーザーにのみメッセージが送信されることを確実にするには、サインアップ時にユーザーが以下の情報を入力することを必須とするように Amazon Cognito ユーザープールを設定します。

1. E メールアドレスおよび電話番号。

2. Amazon Cognito がその E メールアドレスまたは電話番号に送信する検証コード。24 時間が経過し、ユーザーのコードまたはリンクが有効でなくなった場合は、ResendConfirmationCode API オペレーションを呼び出して、新しいコードまたはリンクを生成して送信します。

検証コードを入力することで、コードを受信したメールボックスまたは電話へのアクセス権があるユーザーであることが証明されます。ユーザーがコードを入力すると、Amazon Cognito が以下を行うことによってユーザープールのユーザーに関する情報を更新します。

• ユーザーのステータスを CONFIRMED に設定する。

• ユーザーの属性を更新し、E メールアドレスまたは電話番号が検証されていることを示す。

この情報は、Amazon Cognito コンソールを使用して表示できます。または、AdminGetUser API オペレーション、AWS CLI を使用した admin-get-user コマンド、またはいずれかの AWS SDK の対応するアクションを使用できます。

ユーザーに検証済みの連絡方法がある場合は、ユーザーがパスワードリセットをリクエストする時に、Amazon Cognito が自動的にメッセージをユーザーに送信します。

E メールまたは電話による検証を求めるようにユーザープールを設定するには

ユーザーの E メールアドレスと電話番号を確認することで、ユーザーに連絡できることを確認します。AWS Management Console で以下の手順を実行し、ユーザーに E メールアドレスまたは電話番号の確認を要求するようにユーザープールを設定します。

注記

アカウントにまだユーザープールがない場合は、「ユーザープールの開始方法。」を参照してください。

Original console

ユーザープールを設定するには

1. AWS Management Consoleにサインインし、Amazon Cognito コンソール (https://console.aws.amazon.com/cognito) を開きます。プロンプトが表示されたら、AWS 認証情報を入力します。

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

3. [ユーザープール] ページで、設定するユーザープールを選択します。

4. 左側のナビゲーションメニューで、[MFA and verifications] を選択します。

5. [Which attributes do you want to verify?] (どの属性を検証する必要がありますか?) で、以下のいずれかのオプションを選択します。

   

   E メール

   このオプションを選択すると、ユーザーがサインアップするときに Amazon Cognito が検証コードを送信します。通常 E メールでユーザーと通信する場合は、このオプションを選択してください。たとえば、請求明細、注文書、特価販売を使用する場合は、検証済みの E メールアドレスを使用する必要があります。

   電話番号

   このオプションを選択すると、Amazon Cognito はユーザーがサインアップする際に SMS メッセージ経由で検証コードを送信します。通常 SMS メッセージでユーザーと通信する場合は、このオプションを選択してください。例えば、配信通知、予約確認、または警告を送信する場合は、検証済みの電話番号を使用します。

   E メールまたは電話番号

   すべてのユーザーに同じ検証済みの連絡方法を要求する必要がない場合は、このオプションを選択してください。この場合、アプリのサインアップページで、希望する連絡方法のみを検証するようにユーザーに求めることができます。Amazon Cognito が検証コードを送信するときは、アプリからの SignUp リクエストで指定された連絡方法にコードが送信されます。ユーザーが E メールアドレスと電話番号の両方を入力し、アプリが SignUp リクエストに両方の連絡方法を指定する場合、Amazon Cognito は検証コードを電話番号のみに送信します。

   ユーザーが E メールアドレスと電話番号の両方を検証することを必須としている場合は、このオプションを選択してください。Amazon Cognito は、ユーザーのサインアップ時に 1 つの連絡方法を検証するので、アプリがユーザーのサインイン後にもう一方の連絡方法を検証する必要があります。詳細については、「ユーザーに E メールアドレスと電話番号の両方の確認を要求する場合」を参照してください。

   なし

   このオプションを選択すると、Amazon Cognito はユーザーのサインアップ時に検証コードを送信しません。このオプションは、Amazon Cognito からの検証コードを使用せずに、少なくとも 1 つの連絡方法を検証するカスタムの認証フローを使用している場合に選択します。例えば、特定のドメインに属する E メールアドレスを自動的に確認するサインアップ前 Lambda トリガーを使用することができます。

   ユーザーの連絡先情報を検証しない場合は、アプリケーションを使用できない場合があります。以下を行うには、ユーザーの連絡情報の検証が必要となる点にご注意ください。

   • [Reset their passwords] (パスワードのリセット) — ユーザーが ForgotPassword API アクションを呼び出すオプションをアプリケーションで選択すると、Amazon Cognito はユーザーの E メールアドレスまたは電話番号に一時パスワードを送信します。Amazon Cognito がこのパスワードを送信するのは、ユーザーが検証済みの連絡方法を少なくとも 1 つ持っている場合のみです。

   • [Sign in by using an email address or phone number as an alias] (E メールアドレスまたは電話番号をエイリアスとして使用してサインインする) — これらのエイリアスを許可するようにユーザープールを設定した場合、ユーザーは、検証済みである場合にのみ、そのエイリアスを使用してサインインできます。詳細については、「ログイン属性のカスタマイズ」を参照してください。

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

New console

ユーザープールを設定するには

1. [Amazon Cognito console] (Amazon Connect コンソール) に移動します。プロンプトが表示されたら、AWS 認証情報を入力します。

2. ナビゲーションペインで、[User Pools] (ユーザープール) を選択します。リストから既存のユーザープールを選択するか、ユーザープールを作成します。

3. Sign-up experience] (サインアップエクスペリエンス) タブを選択して、[Attribute verification and user account confirmation] (属性の検証とユーザーアカウントの確認) を検索します。Edit (編集) を選択します。

4. [Cognito-assisted verification and confirmation] (Cognito アシストの検証と確認) を有効化するかどうかを選択して、Amazon Cognito がユーザーのサインアップ時に選択したユーザー連絡先属性にメッセージを送信させるか、ユーザープロファイルを作成します。Amazon Cognito が送信するメッセージは、ユーザーがその受信を確認した後、属性を検証し、サインインするためのユーザープロファイルを確認するコードまたはリンクをユーザーに提供します。

   注記

   [Cognito-assisted verification and confirmation] (Cognito アシストの検証と確認) を無効にして、API アクションまたは Lambda トリガーを使用して属性を検証し、ユーザーを確認することもできます。

   このオプションを選択すると、Amazon Cognito はユーザーのサインアップ時に検証コードを送信しません。このオプションは、Amazon Cognito からの検証コードを使用せずに、少なくとも 1 つの連絡方法を検証するカスタムの認証フローを使用している場合に選択します。例えば、特定のドメインに属する E メールアドレスを自動的に確認するサインアップ前 Lambda トリガーを使用することができます。

   ユーザーの連絡先情報を検証しない場合は、アプリケーションを使用できない場合があります。以下を行うには、ユーザーの連絡情報の検証が必要となる点にご注意ください。

   • [Reset their passwords] (パスワードのリセット) — ユーザーが ForgotPassword API アクションを呼び出すオプションをアプリケーションで選択すると、Amazon Cognito はユーザーの E メールアドレスまたは電話番号に一時パスワードを送信します。Amazon Cognito がこのパスワードを送信するのは、ユーザーが検証済みの連絡方法を少なくとも 1 つ持っている場合のみです。

   • [Sign in by using an email address or phone number as an alias] (E メールアドレスまたは電話番号をエイリアスとして使用してサインインする) — これらのエイリアスを許可するようにユーザープールを設定した場合、ユーザーは、検証済みである場合にのみ、そのエイリアスを使用してサインインできます。詳細については、「ログイン属性のカスタマイズ」を参照してください。

5. [Attributes to verify] (検証する属性) を以下から選択します。

   SMS メッセージを送信し、電話番号を確認する

   ユーザーがサインアップすると Amazon Cognito が SMS メッセージで検証コードを送信します。通常 SMS メッセージでユーザーと通信する場合は、このオプションを選択してください。例えば、配信通知、予約確認、または警告を送信する場合は、検証済みの電話番号を使用します。アカウントが確認されると、ユーザーの電話番号が検証済み属性になります。ユーザーの E メールアドレスを確認して通信するには、追加のアクションを実行する必要があります。

   E メールメッセージを送信し、E メールアドレスを確認する

   ユーザーがサインアップすると Amazon Cognito が E メール経由で検証コードを送信します。通常 E メールでユーザーと通信する場合は、このオプションを選択してください。たとえば、請求明細、注文書、特価販売を使用する場合は、検証済みの E メールアドレスを使用する必要があります。アカウントが確認されると、ユーザーのメールアドレスが検証済み属性になります。ユーザーの電話番号を確認して通信するには、追加のアクションを実行する必要があります。

   電話番号が利用可能な場合は SMS メッセージを送信し、そうでない場合は E メールメッセージを送信する

   すべてのユーザーに同じ検証済みの連絡方法を要求する必要がない場合は、このオプションを選択してください。この場合、アプリのサインアップページで、希望する連絡方法のみを検証するようにユーザーに求めることができます。Amazon Cognito が検証コードを送信するときは、アプリからの SignUp リクエストで指定された連絡方法にコードが送信されます。ユーザーが E メールアドレスと電話番号の両方を入力し、アプリが SignUp リクエストに両方の連絡方法を指定する場合、Amazon Cognito は検証コードを電話番号のみに送信します。

   ユーザーが E メールアドレスと電話番号の両方を検証することを必須としている場合は、このオプションを選択してください。Amazon Cognito は、ユーザーのサインアップ時に 1 つの連絡方法を検証するので、アプリがユーザーのサインイン後にもう一方の連絡方法を検証する必要があります。詳細については、「ユーザーに E メールアドレスと電話番号の両方の確認を要求する場合」を参照してください。

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

E メールアドレスまたは電話による検証を使用した認証フロー

ユーザープールで連絡先情報の検証をユーザーに要求する場合、ユーザーがアプリにサインアップした後のフローを容易にする必要があります。

1. ユーザーは、ユーザー名、メールアドレス、電話番号やその他の属性を入力してアプリにサインアップします。

2. Amazon Cognito サービスは、アプリからサインアップリクエストを受け取ります。サインアップに必要なすべての属性がリクエストに含まれることを確認した後で、サービスはサインアッププロセスを完了し、確認コードをユーザーの電話 (SMS メッセージ) または E メールに送信します。コードは 24 時間有効です

3. サービスは、サインアップが完了しユーザーアカウントが確認保留であることを返します。応答には、確認コードの送信先に関する情報が含まれます。この時点でユーザーアカウントは未確認状態になり、ユーザーのメールアドレスと電話番号は未確認です。

4. アプリは、ユーザーに確認コードを入力するよう求めるメッセージを表示できます。ユーザーは、コードをすぐに入力する必要はありません。ただし、確認コードを入力するまでユーザーはサインインできません。

5. ユーザーがアプリに確認コードを入力します。

6. アプリは、Amazon Cognito サービスにコードを送信する ConfirmSignUp を呼び出します。これは、コードを検証し、コードが正しい場合はユーザーのアカウントを確認済み状態に設定します。ユーザーアカウントが正常に確認されると、Amazon Cognito サービスが自動的に、E メールアドレスまたは電話番号を確認するために使用された属性を検証済みとしてマークします。この属性の値が変更されていない場合、ユーザーはそれを再度確認する必要はありません。

7. この時点で、ユーザーアカウントは確認済みの状態になっており、ユーザーはサインインできます。

ユーザーに E メールアドレスと電話番号の両方の確認を要求する場合

Amazon Cognito は、ユーザーのサインアップ時に 1 つの連絡方法しか検証しません。Amazon Cognito が E メールアドレスまたは電話番号のどちらを検証するかを選択する必要がある場合は、SMS メッセージ経由で検証コードを送信して電話番号を検証することを選択します。例えば、ユーザーが E メールアドレスと電話番号のいずれかを検証できるようにユーザープールを設定する場合、およびアプリがサインアップ時にこれら両方の属性を提供する場合、Amazon Cognito は電話番号のみを検証します。ユーザーが電話番号を検証したら、Amazon Cognito がユーザーのステータスを CONFIRMED に設定し、ユーザーはアプリにサインインできるようになります。

ユーザーがアプリにサインインした後、サインアップ時に検証されなかった連絡方法を検証するオプションを提示することができます。この 2 つ目の方法を検証するには、アプリで VerifyUserAttribute API アクションを呼び出します。このアクションには AccessToken パラメータが必要で、Amazon Cognito は認証されたユーザーにアクセストークンしか提供しないことに注意してください。したがって、2 つ目の連絡方法は、ユーザーがサインインした後にのみ検証できます。

E メールアドレスと電話番号の両方を検証するようにユーザーに求める場合は、以下のように行います。

1. E メールアドレスまたは電話番号を検証することをユーザーに許可するようにユーザープールを設定します。

2. アプリのサインアップフローで、E メールアドレスおよび電話番号の両方を入力するようユーザーに求めます。SignUp API アクションを呼び出し、UserAttributes パラメータの E メールアドレスおよび電話番号を指定します。この時点で、Amazon Cognito がユーザーの携帯電話に検証コードを送信します。

3. アプリのインターフェイスで、ユーザーが検証コードを入力する確認ページを提示します。ユーザーを確認するには、ConfirmSignUp API アクションを呼び出します。この時点で、ユーザーのステータスは CONFIRMED となり、ユーザーの電話番号は検証されますが、E メールアドレスはまだ検証されていません。

4. サインインページを提示し、ユーザーを認証するには、InitiateAuth API アクションを呼び出します。ユーザーが認証されると、Amazon Cognito がアプリにアクセストークンを返します。

5. GetUserAttributeVerificationCode API アクションを呼び出します。リクエストで次のパラメータを指定します。

   • AccessToken – ユーザーのサインイン時に Amazon Cognito が返したアクセストークン。

   • AttributeName – "email" を属性値として指定します。

   Amazon Cognito がユーザーの E メールアドレスに検証コードを送信します。

6. ユーザーが検証コードを入力する確認ページを提示します。ユーザーがコードを入力したら、VerifyUserAttribute API アクションを呼び出します。リクエストで次のパラメータを指定します。

   • AccessToken – ユーザーのサインイン時に Amazon Cognito が返したアクセストークン。

   • AttributeName – "email" を属性値として指定します。

   • Code – ユーザーが提供した検証コード。

   この時点で、E メールアドレスが検証されます。

ユーザーにアプリケーションへのサインアップを許可するが管理者として確認する

1. ユーザーは、ユーザー名、メールアドレス、電話番号やその他の属性を入力してアプリにサインアップします。

2. Amazon Cognito サービスは、アプリからサインアップリクエストを受け取ります。サインアップに必要なすべての属性がリクエストに含まれることを確認した後で、サービスはサインアッププロセスを完了し、アプリにサインアップが完了し確認が保留中であることをアプリに返します。この時点でユーザーのアカウントは未確認状態です。アカウントが確認されるまで、ユーザーはサインインすることはできません。

3. 管理者は、Amazon Cognito コンソール ([Users] (ユーザー) タブでユーザーアカウントを見つけて [Confirm] (確認) ボタンをクリックする)、または CLI (admin-confirm-sign-up コマンドを選択する) でユーザーのアカウントを確認します。[確認] ボタンと admin-confirm-sign-up コマンドは、AdminConfirmSignUp API を使用して確認を行います。

4. この時点で、ユーザーアカウントは確認済みの状態になっており、ユーザーはサインインできます。

シークレットハッシュ 値の計算

ベストプラクティスとして、機密アプリケーションクライアントにクライアントシークレットを割り当てます。アプリケーションクライアントにクライアントシークレットを割り当てる場合、Amazon Cognito ユーザープール API リクエストには、リクエスト本文にクライアントシークレットを含むハッシュを含める必要があります。以下のリストにある API オペレーションのクライアントシークレットに関する知識を検証するには、クライアントシークレットをアプリケーションのクライアント ID とユーザーのユーザー名と連結し、その文字列を base64 でエンコードします。

以下の Amazon Cognito ユーザープール API は、SecretHash パラメータにクライアントシークレットのハッシュ値を受け入れます。

• ConfirmForgotPassword

• ConfirmSignUp

• ForgotPassword

• ResendConfirmationCode

• SignUp

また、以下の API は、認証パラメータまたはチャレンジレスポンス内の SECRET_HASH パラメータにクライアントシークレットのハッシュ値を受け入れます。

API オペレーション	SECRET_HASH の親パラメータ
InitiateAuth	AuthParameters
AdminInitiateAuth	AuthParameters
RespondToAuthChallenge	ChallengeResponses
AdminRespondToAuthChallenge	ChallengeResponses

シークレットハッシュ値は、Base 64 でエンコードされたキー付きハッシュメッセージ認証コード (HMAC) であり、ユーザープールクライアントおよびユーザー名、さらにメッセージ内のクライアント ID を使用して計算されたものです。次の擬似コードは、この値の計算方法を示します。この擬似コードで + は連結を表し、HMAC_SHA256 は HmacSHA256 を使用して HMAC 値を生成する関数を、Base64 は Base-64 でエンコードされたバージョンのハッシュ出力を生成する関数を示します。

Base64 ( HMAC_SHA256 ( "Client Secret Key", "Username" + "Client Id" ) )

SecretHash パラメータの計算方法と使用方法の詳細な概要については、AWS ナレッジセンターの「Amazon Cognito ユーザープール API で発生した『クライアント <client-id> のシークレットハッシュを検証できません』というエラーをトラブルシューティングするにはどうすればよいですか」を参照してください。

サーバー側の Java アプリケーションコードで、次のコード例を使用できます。

Java

import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
 
public static String calculateSecretHash(String userPoolClientId, String userPoolClientSecret, String userName) {
    final String HMAC_SHA256_ALGORITHM = "HmacSHA256";
    
    SecretKeySpec signingKey = new SecretKeySpec(
            userPoolClientSecret.getBytes(StandardCharsets.UTF_8),
            HMAC_SHA256_ALGORITHM);
    try {
        Mac mac = Mac.getInstance(HMAC_SHA256_ALGORITHM);
        mac.init(signingKey);
        mac.update(userName.getBytes(StandardCharsets.UTF_8));
        byte[] rawHmac = mac.doFinal(userPoolClientId.getBytes(StandardCharsets.UTF_8));
        return Base64.getEncoder().encodeToString(rawHmac);
    } catch (Exception e) {
        throw new RuntimeException("Error while calculating ");
    }
}

Python

import sys
import hmac, hashlib, base64 
username = sys.argv[1] 
app_client_id = sys.argv[2] 
key = sys.argv[3] 
message = bytes(sys.argv[1]+sys.argv[2],'utf-8') 
key = bytes(sys.argv[3],'utf-8') 
secret_hash = base64.b64encode(hmac.new(key, message, digestmod=hashlib.sha256).digest()).decode() 
print("SECRET HASH:",secret_hash)

E メールまたは電話番号の確認なしでユーザーアカウントを確認する

検証コードを要求したり、E メールまたは電話番号を検証したりすることなくサインアップ時にユーザーアカウントを自動的に確認するには、サインアップ前の Lambda トリガーを使用できます。この方法で確認されたユーザーは、コードを受け取らないですぐにサインインできます。

このトリガーによって検証されたユーザーのメールまたは電話番号をマーキングすることもできます。

注記

これはユーザーが始めるにあたって便利な方法ですが、E メールまたは電話番号を少なくとも 1 つ自動検証することをお勧めします。そうしないと、ユーザーがパスワードを忘れた際に復旧できないままになる場合があります。

ユーザーがサインアップ時に検証コードを受信して入力することを必須とせず、サインアップ前の Lambda トリガーで E メールと電話番号を自動検証しない場合は、そのユーザーアカウントに検証済みの E メールアドレスまたは電話番号が存在しないリスクが生じます。ユーザーはメールアドレスまたは電話番号を後で確認できます。ただし、パスワードを忘れて確認済みの E メールアドレスまたは電話番号がない場合、パスワードを忘れた場合のフローで検証コードをユーザーに送信するために確認済みの E メールまたは電話番号が必要となるため、ユーザーはアカウントからロックアウトされます。

ユーザーが E メールまたは電話番号を変更するときに確認する

ユーザーがアプリで自分の E メールアドレスまたは電話番号を更新すると、その属性を自動的に検証するようにユーザープールを設定した場合、Amazon Cognito は検証コード付きのメッセージをすぐにユーザーに送信します。その後、ユーザーは検証メッセージからアプリにコードを提供する必要があります。その後、アプリは VerifyUserAttribute API リクエストでこのコードを送信し、新しい属性値の検証を完了します。

ユーザープールで更新された E メールアドレスまたは電話番号の検証がユーザーに要求されない場合、Amazon Cognito はただちに更新された email または phone_number 属性の値を変更し、その属性を未検証としてマークします。ユーザーは、未確認の E メールまたは電話番号でサインインできません。その属性をサインインエイリアスとして使用するには、更新された値の検証を完了する必要があります。

ユーザープールで更新された E メールアドレスまたは電話番号の検証がユーザーに要求される場合、Amazon Cognito はユーザーが新しい属性値を検証するまで、属性を検証されたままにし、元の値に設定します。属性がサインイン用のエイリアスである場合、検証によって属性が新しい値に変更されるまで、ユーザーは元の属性値を使用してサインインできます。更新された属性の検証をユーザーに要求するようにユーザープールを設定する方法の詳細については、「E メールまたは電話による検証の設定」を参照してください。

検証メッセージは、カスタムメッセージの Lambda トリガーを使用してカスタマイズできます。詳細については、「カスタムメッセージの Lambda トリガー」を参照してください。ユーザーの E メールアドレスや電話番号が未確認の場合、アプリはユーザーに属性を確認する必要があることを通知し、ユーザーが新しい E メールアドレスや電話番号を確認するためのボタンやリンクを提供する必要があります。

管理者またはデベロッパーが作成するユーザーアカウントの確認および検証プロセス

管理者またはデベロッパーが作成したユーザーアカウントは常に確認済み状態にあるため、ユーザーは確認コードを入力する必要はありません。Amazon Cognito サービスがこれらのユーザーに送信する招待メッセージには、ユーザー名と一時パスワードが含まれています。ユーザーは、サインインする前にパスワードを変更する必要があります。詳細について、は、「E メールメッセージと SMS メッセージのカスタマイズ」の「管理者としてのユーザーアカウントの作成」と「Lambda トリガーを使用したユーザープールワークフローのカスタマイズ」のカスタムメッセージのトリガーを参照してください。

インポート済みユーザーアカウントの確認および検証プロセス

AWS Management Console、CLI、または API (「CSV ファイルからユーザープールへのユーザーのインポート」を参照) でユーザーのインポート機能を使用して作成されたユーザーアカウントは常に確認済み状態にあるため、ユーザーは確認コードを入力する必要はありません。招待メッセージは送信されません。ただし、インポートされたユーザーアカウントでは、サインインする前にまず ForgotPassword API を呼び出してコードをリクエストし、次に、提供されたコードを使用して ConfirmForgotPassword API を呼び出すことによってパスワードを作成する必要があります。詳細については、「インポートされたユーザーにパスワードをリセットするように要求」を参照してください。

ユーザーアカウントがインポートされたときに、ユーザーの E メールまたは電話番号は確認済みとしてマークする必要があります。したがって、ユーザーがサインインする際に認証は必要ありません。

アプリケーションのテスト中に E メールを送信する

ユーザープールのクライアントアプリでアカウントを作成および管理する場合は、Amazon Cognito がユーザーに E メールメッセージを送信します。E メール検証を必須とするようにユーザープールを設定した場合は、以下のタイミングで Amazon Cognito が E メールを送信します。

• ユーザーのサインアップ時。

• ユーザーが E メールアドレスを更新する際。

• ユーザーが ForgotPassword API アクションを呼び出すアクションを実行する際。

• 管理者としてユーザーアカウントを作成する際。

E メールを開始するアクションに応じて、検証コードまたは仮パスワードが含まれます。ユーザーは、これらの E メールを受け取り、メッセージを理解する必要があります。そうしないと、アプリにサインインして使用できない場合があります。

E メールが正常に送信され、メッセージの内容が正しいことを確認するには、Amazon Cognito からの E メール配信を開始するアプリのアクションをテストします。たとえば、アプリでサインアップページを使用するか、SignUp API アクションを使用して、テスト用メールアドレスでサインアップすることで E メールを配信できます。この方法でテストする場合は、次の点に注意してください。

[Important] (重要)

Amazon Cognito からの E メールを開始するアクションをテストするために E メールアドレスを使用する場合は、偽の E メールアドレス (メールボックスが存在しないメールアドレス) は使用しないでください。ハードバウンスを発生させずに Amazon Cognito からの E メールを受信する実際の E メールアドレスを使用します。

ハードバウンスは、Amazon Cognito が受取人のメールボックスへの E メールの配信に失敗した場合に発生します。これは、常にメールボックスが存在しない場合に発生します。

Amazon Cognito は、AWS アカウントから送信できる、ハードバウンスが持続的に発生する E メールの数を制限します。

E メールを配信するアクションをテストする場合、次のいずれかの E メールアドレスを使用してハードバウンスを回避します。

• テスト用に所有し、使用している E メールアカウントのメールアドレス。独自の E メールアドレスを使用すると、Amazon Cognito が送信する E メールを受け取ります。この E メールでは、検証コードを使用して、アプリのサインアップエクスペリエンスをテストできます。ユーザープールの E メールメッセージをカスタマイズした場合は、正しく表示されていることを確認します。

• メールボックスシミュレーターのアドレス ([e-mail])。シミュレーターのアドレスを使用する場合、Amazon Cognito は E メールを正常に送信しますが、それを表示することはできません。このオプションは、検証コードを使用する必要がなく、E メールのメッセージを確認する必要がない場合に役立ちます。

• [e-mail] または [e-mail] などの、任意のラベルを使用するメールボックスシミュレーターのアドレス。Amazon Cognito はこれらのアドレスに E メールを正常に送信しますが、送信された E メールを表示することはできません。このオプションは、複数のテストユーザーをユーザープールに追加してサインアッププロセスをテストし、各テストユーザーに一意の E メールアドレスがある場合に便利です。