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

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

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

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

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

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

サインアップ時のパスワード

Amazon Cognito では、以下の条件を除き、サインアップ時にすべてのユーザーのパスワードが必要です。これらの条件がすべて満たされている場合は、サインアップオペレーションでパスワードを省略できます。

1. パスワードレスサインインは、ユーザープールとアプリケーションクライアントでアクティブです。

2. アプリケーションは、 AWS SDK の認証モジュールを使用してカスタムビルドされます。マネージドログインとホストされた UI には、常にパスワードが必要です。

3. ユーザーは、E メールまたは SMS メッセージワンタイムパスワード (OTPs) などのパスワードレスサインインメソッドの属性値を、許可する範囲で指定します。例えば、E メールと電話の OTP でサインインを許可する場合、ユーザーは電話番号または E メールアドレスを指定できますが、E メールのみでサインインを許可する場合は、E メールアドレスを指定する必要があります。

4. ユーザープールは、ユーザーがパスワードレスサインインで使用できる属性を自動的に検証します。

5. 特定の SignUp リクエストに対して、ユーザーは Password パラメータの値を指定しません。

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

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

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

登録済み (未確認)

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

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

確認済み

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

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

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

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

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

パスワードの強制変更

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

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

Disabled

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

その他のリソース

• Amazon Cognito による非アクティブなユーザーアカウントの検出と修正

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ユーザー属性を確認および検証するその他のアクション

次のユーザーアクティビティは、ユーザー属性を検証します。これらの属性を自動的に検証するように設定する必要はありません。リストされたアクションは、すべてのケースで検証済みとしてマークします。

E メールアドレス

1. E メールワンタイムパスワード (OTP) を使用してパスワードレス認証を正常に完了しました。

2. E メール OTP を使用して多要素認証 (MFA) を正常に完了しました。

電話番号

1. SMS OTP でパスワードレス認証を正常に完了しました。

2. SMS OTP を使用して MFA を正常に完了しました。

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

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

注記

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

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

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

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

3. サインアップメニューを選択し、属性の検証とユーザーアカウントの確認を見つけます。[編集] を選択します。

4. [Cognito による検証と確認] で、[Cognito が検証と確認のためのメッセージを自動的に送信することを許可] するかどうかを選択します。この設定を有効にすると、Amazon Cognito は、ユーザーのサインアップ時またはユーザープロファイルの作成時に選択したユーザー連絡先属性にメッセージを送信します。サインイン用の属性を検証し、ユーザープロファイルを確認するために、Amazon Cognito はコードまたはリンクをメッセージでユーザーに送信します。次に、ユーザーは UI にコードを入力し、アプリが ConfirmSignUp または AdminConfirmSignUp API リクエストで確認できるようにする必要があります。

   注記

   [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 メールアドレスが検証されます。

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

ユーザープールで確認メッセージを自動的に送信しないにも関わらず、誰でもアカウントにサインアップできるようにしたい場合があります。このモデルでは、たとえば、新しい登録リクエストを人間が確認したり、サインアップの一括検証と処理を行ったりする余地があります。Amazon Cognito コンソール、または IAM 認証された API オペレーション AdminConfirmSignUp を使用して新しいユーザーアカウントを確認できます。ユーザープールが確認メッセージを送信するかどうかにかかわらず、ユーザーアカウントを管理者として確認できます。

この方法では、ユーザーのセルフサービスサインアップを確認することしかできません。管理者として作成したユーザーを確認するには、Permanent を True に設定した AdminSetUserPassword API リクエストを作成します。

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

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

3. ユーザーのアカウントを確認します。アカウントを確認するには、 にサインイン AWS Management Console するか、 AWS 認証情報を使用して API リクエストに署名する必要があります。

   1. Amazon Cognito コンソールでユーザーを確認するには、ユーザーメニューに移動し、確認するユーザーを選択し、アクションメニューから確認を選択します。

   2. AWS API または CLI でユーザーを確認するには、 で AdminConfirmSignUp API リクエストを作成するか、admin-confirm-sign-up を作成します AWS CLI。

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

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

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

シークレットハッシュを持つクライアントにアプリがユーザーをサインインすると、ユーザープールのサインイン属性の値をシークレットハッシュのユーザー名要素として使用できます。アプリが REFRESH_TOKEN_AUTH による認証オペレーションで新しいトークンをリクエストする場合、ユーザー名要素の値はサインイン属性によって異なります。ユーザープールにサインイン属性として username がない場合は、ユーザーのアクセストークンまたは ID トークンの sub クレームからのシークレットハッシュユーザー名の値を設定します。username がサインイン属性である場合は、username クレームからのシークレットハッシュユーザー名の値を設定します。

以下の 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 アプリケーションコードで、次のコード例を使用できます。

Shell

echo -n "[username][app client ID]" | openssl dgst -sha256 -hmac [app client secret] -binary | openssl enc -base64

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 メールアドレスを入力できます。アプリで E メールアドレスまたは電話番号を更新すると、Amazon Cognito は新しい属性値の所有権を検証するコードを含むメッセージをすぐに送信できます。これらの検証コードの自動送信を有効にするには、「」を参照してくださいE メールまたは電話による検証の設定。

検証コードを受け取るユーザーは、VerifyUserAttribute リクエストでそのコードを Amazon Cognito に返す必要があります。コードを指定すると、その属性は検証済みとしてマークされます。通常、ユーザーが E メールアドレスまたは電話番号を更新するときは、ユーザーが新しい値を使用してサインインし、メッセージを受信する前に、その値を所有していることを確認する必要があります。ユーザープールには、ユーザーが E メールアドレスまたは電話番号の更新を確認する必要があるかどうかを決定する設定可能なオプションがあります。

このオプションはユーザープールプロパティ ですAttributesRequireVerificationBeforeUpdate。CreateUserPool または UpdateUserPool リクエストで設定するか、Amazon Cognito コンソールのサインアップメニューで更新が保留中のときに元の属性値をアクティブのままにします。

ユーザープールが E メールアドレスと電話番号の更新を処理する方法は、ユーザープールのユーザー名設定に接続されます。ユーザープールのユーザー名は、サインイン名が E メールアドレス、電話番号、またはその両方であるユーザー名属性設定に含めることができます。また、属性がサインイン名でありusername、代替サインイン名として E メールアドレス、電話番号、または優先ユーザー名であるエイリアス属性設定に含めることもできます。詳細については、「ログイン属性のカスタマイズ」を参照してください。

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

次の表は、ユーザーがサインイン属性の値を変更したときに、 AttributesRequireVerificationBeforeUpdateとエイリアスの設定によって結果がどのように決定されるかを示しています。

ユーザー名設定	ユーザーが新しい属性を検証する必要がある場合の動作	ユーザーが新しい属性を検証する必要がない場合の動作
ユーザー名属性	元の属性は、検証済み、サインイン対象、元の値のままです。ユーザーが新しい値を検証すると、Amazon Cognito は属性値を更新し、検証済みのマークを付け、サインインの対象にします。	Amazon Cognito は属性を新しい値に更新します。新しい値はサインインの対象となります。ユーザーが新しい値を検証すると、Amazon Cognito はそれを検証済みとしてマークします。
エイリアス属性	元の属性は、検証済み、サインイン対象、元の値のままです。ユーザーが新しい値を検証すると、Amazon Cognito は属性値を更新し、検証済みのマークを付け、サインインの対象にします。	Amazon Cognito は属性を新しい値に更新します。元の属性値も新しい属性値もサインインの対象ではありません。ユーザーが新しい値を検証すると、Amazon Cognito は属性値を更新し、検証済みのマークを付け、サインインの対象にします。

例 1

ユーザー 1 は、E メールアドレスと[e-mail]ユーザー名 user1 (エイリアス属性) を使用してアプリケーションにサインインします。ユーザープールは、サインイン属性の更新を検証し、検証メッセージを自動的に送信するように設定されています。E メールアドレスを に更新するようリクエストします[e-mail]。検証 E メールが に送信[e-mail]され、E メールアドレス でのみ再度サインインできます[e-mail]。その後、検証コードを入力し、E メールアドレス でのみ再度サインインできます[e-mail]。

例 2

ユーザー 2 [e-mail]は、E メールアドレスとユーザー名 (エイリアス属性) を使用してアプリケーションにサインインします。ユーザープールは、サインイン属性の更新を検証せず、検証メッセージを自動的に送信するように設定されています。E メールアドレスを に更新するようリクエストします[e-mail]。検証 E メールが に送信[e-mail]され、再度サインインすることはできません。その後、検証コードを入力し、E メールアドレス でのみ再度サインインできます[e-mail]。

例 3

ユーザー 3 は、E メールアドレスを使用してアプリケーションにサインイン[e-mail]し、ユーザー名 (ユーザー名属性) がありません。ユーザープールは、サインイン属性の更新を検証せず、検証メッセージを自動的に送信するように設定されています。E メールアドレスを に更新するようリクエストします[e-mail]。で検証 E メールを受信しますが[e-mail]、検証コードで追加のアクションを実行することなく、すぐにサインインできます。

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

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

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

、CLI AWS Management Console、または 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 メールを配信できます。この方法でテストする場合は、次の点に注意してください。

[重要]

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 メールアドレスがある場合に便利です。