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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

シークレットハッシュ値は、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 トリガーを使用できます。この方法で確認されたユーザーは、コードを受け取らないですぐにサインインできます。

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

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

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

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