クライアント側の認証フローサーバー側の認証フローカスタム認証フロー組み込みの認証フローとチャレンジカスタム認証フローとチャレンジカスタム認証フローでSRPパスワード検証を使用する管理認証フローユーザー移行の認証フロー

ユーザープール認証フロー

Amazon Cognito には、ユーザーを認証する方法がいくつか用意されています。ドメインの有無にかかわらず、すべてのユーザープールはユーザープールでユーザーを認証できますAPI。ユーザープールにドメインを追加すると、ユーザープールエンドポイントを使用できます。ユーザープールは、さまざまな承認モデルとリクエストのAPIリクエストフローAPIをサポートしています。

ユーザーのアイデンティティを検証するため、Amazon Cognito では、パスワードの他にも新しいタイプのチャレンジが導入されています。Amazon Cognito 認証では、通常、次の順序で 2 つのAPIオペレーションを実装する必要があります。

認証が失敗するか、Amazon Cognito がユーザーにトークンを発行するまで、ユーザーは連続してチャレンジに回答して認証を進めます。カスタム認証フローをサポートするために、さまざまなチャレンジを含むプロセスで Amazon Cognito でこれらの手順を繰り返すことができます。

Authentication flow diagram showing user, mobile/web app, and user pool interactions for token issuance.

通常、アプリケーションはユーザーから情報を収集するプロンプトを生成し、その情報をAPIリクエストで Amazon Cognito に送信します。多要素認証 () でユーザーを設定しているユーザープールのInitiateAuthフローを考えてみましょうMFA。

アプリケーションは、ユーザーにユーザー名とパスワードの入力を求めます。
ユーザー名とパスワードをパラメータとして InitiateAuth に含めます。
Amazon Cognito から SMS_MFA チャレンジとセッション識別子が返されます。
アプリは、ユーザーに電話からMFAコードの入力を求めます。
そのコードとセッション ID を RespondToAuthChallenge リクエストに含めます。

ユーザープールの機能によっては、アプリケーションが Amazon Cognito からトークンを取得する前に、InitiateAuth へのいくつかのチャレンジに対応することが必要になります。Amazon Cognito は、各リクエストへの応答にセッション文字列を含めます。API リクエストを認証フローに結合するには、前のリクエストに対するレスポンスのセッション文字列を後続の各リクエストに含めます。デフォルトでは、セッション文字列が期限切れになる前に、ユーザーに各チャレンジを完了するまでに 3 分間が与えられます。この期間を調整するには、アプリケーションクライアントの認証フローセッション持続期間を変更します。次の手順では、アプリクライアントの構成で、この設定を変更する方法について説明します。

注記

認証フローセッションの期間設定は、Amazon Cognito ユーザープールによる認証に適用されますAPI。Amazon Cognito がホストする UI では、多要素認証の場合はセッション時間を 3 分、パスワードリセットコードの場合は 8 分に設定しています。

アプリクライアントの詳細については、「アプリケーションクライアントでのアプリケーション固有の設定」を参照してください。

AWS Lambda トリガーを使用して、ユーザーの認証方法をカスタマイズできます。トリガーは独自のチャレンジを認証フローの一部として発行し検証を行います。

また、安全なバックエンドサーバーでは、管理者の認証フローを使用することもできます。ユーザー移行の認証フローを使用すると、ユーザーがパスワードをリセットしなくてもユーザー移行できます。

サインインの試行の失敗に対する、Amazon Cognito ロックアウト動作

認証されていないサインインまたはIAM認証されたサインインをパスワードで 5 回失敗した後、Amazon Cognito は 1 秒間ユーザーをロックアウトします。ロックアウトの期間は、試行が 1 回失敗するたびに 2 倍になり、最大で約 15 分になります。ロックアウト期間中に試行すると Password attempts exceeded 例外が生成され、その後のロックアウト期間の長さには影響しません。サインイン試行の累積失敗回数 n (Password attempts exceeded 例外を含まない) に対して、Amazon Cognito はユーザーを 2^(n-5) 秒間ロックアウトします。ロックアウトを n=0 初期状態にリセットするには、ユーザーは、ロックアウト期間後にサインインに成功するか、連続 15 分間、サインイン試行を開始してはなりません。この動作は変更される可能性があります。この動作は、パスワードベースの認証も実行しない限り、カスタムチャレンジに適用されません。

クライアント側の認証フロー

以下のプロセスは、 AWS Amplifyまたはを使用して作成するユーザークライアント側のアプリケーションに対して機能しますAWS SDKs。

ユーザーがアプリにユーザー名とパスワードを入力します。
アプリは、ユーザーのユーザー名とセキュアリモートパスワード (SRP) の詳細を使用して InitiateAuth オペレーションを呼び出します。

このAPIオペレーションは、認証パラメータを返します。

注記
アプリは、に組み込まれ AWS ている Amazon Cognito SRP機能を使用してSRP詳細を生成しますSDKs。
アプリが RespondToAuthChallenge 操作を呼び出します。呼び出しが成功すると、Amazon Cognito からユーザーのトークンが返され、認証フローが完了します。

Amazon Cognito に必要なチャレンジが別に存在する場合は、RespondToAuthChallenge を呼び出してもトークンは返されません。代わりに、呼び出しによってセッションが返されます。
がセッションをRespondToAuthChallenge返すと、アプリケーションはRespondToAuthChallenge再度呼び出します。今回はセッションとチャレンジレスポンス (MFAコードなど) を使用します。

サーバー側の認証フロー

ユーザーアプリケーションを持っておらず、代わりに Java、Ruby、または Node.js セキュアバックエンドまたはサーバー側のアプリケーションを使用する場合は、Amazon Cognito ユーザープールAPIに認証されたサーバー側を使用できます。

サーバー側のアプリでのユーザープール認証は、クライアント側のアプリでの認証に似ています。次の点が異なります。

サーバー側のアプリケーションは ( の代わりに) AdminInitiateAuthAPIオペレーションを呼び出しますInitiateAuth。このオペレーションには、 cognito-idp:AdminInitiateAuthとを含むアクセス許可を持つ AWS 認証情報が必要ですcognito-idp:AdminRespondToAuthChallenge。オペレーションからは、必要な認証パラメータが返されます。
サーバー側のアプリケーションに認証パラメータがあると、 ( の代わりに) AdminRespondToAuthChallengeAPIオペレーションを呼び出しますRespondToAuthChallenge。AdminRespondToAuthChallenge API オペレーションは、 AWS 認証情報を指定したときにのみ成功します。

AWS 認証情報を使用した Amazon Cognito APIリクエストの署名の詳細については、 AWS 全般のリファレンス の署名バージョン 4 の署名プロセスを参照してください。

AdminInitiateAuth および AdminRespondToAuthChallengeAPIオペレーションは、次のいずれかの方法で明示的に有効にしない限り、管理者サインインのユーザー認証情報を承諾 username-and-passwordできません。

CreateUserPoolClient または UpdateUserPoolClient を呼び出すときは、ExplicitAuthFlow パラメータに ALLOW_ADMIN_USER_PASSWORD_AUTH (以前は ADMIN_NO_SRP_AUTH と呼ばれています) を含めます。
アプリクライアントの認証フローのリストに ALLOW_ADMIN_USER_PASSWORD_AUTH を追加します。ユーザープールの [App integration] (アプリ統合) タブの [App clients and analytics] (アプリクライアントと分析) でアプリクライアントを設定します。詳細については、「アプリケーションクライアントでのアプリケーション固有の設定」を参照してください。

カスタム認証フロー

Amazon Cognito ユーザープールでは、カスタム認証フローを使用することもできます。これにより、 AWS Lambda トリガーを使用してチャレンジ/レスポンスベースの認証モデルを作成できます。

カスタム認証フローを使用すると、チャレンジとレスポンスサイクルをカスタマイズすることが可能になり、さまざまな要件に対応できます。フローは、使用する認証のタイプを示し、初期認証パラメータを提供する InitiateAuthAPIオペレーションの呼び出しから始まります。Amazon Cognito は、以下のいずれかの情報を使用して InitiateAuth コールに応答します。

ユーザーへのチャレンジ、ならびにセッションおよびパラメータ。
ユーザーが認証に失敗した場合はエラー。
InitiateAuth コールで渡されたパラメータがユーザーのサインインに十分な場合は、ID、アクセス権限、更新トークン。(通常、ユーザーまたはアプリケーションは最初にチャレンジに応答する必要がありますが、カスタムコードはこれを判定する必要があります。)

Amazon Cognito がチャレンジで InitiateAuth コールに応答する場合、アプリは追加の入力を収集して、RespondToAuthChallenge 操作を呼び出します。このコールは、チャレンジ応答を提供し、セッションを返します。Amazon Cognito は、RespondToAuthChallenge コールに対しても InitiateAuth コール同様の対応をします。ユーザーがサインインしている場合、Amazon Cognito はトークンを提供します。ユーザーがサインインしていない場合、Amazon Cognito は別のチャレンジまたはエラーを提供します。Amazon Cognito が別のチャレンジを返した場合、ユーザーが正常にサインインするかエラーが返されるまで、シーケンスが繰り返され、アプリは RespondToAuthChallenge を呼び出します。InitiateAuth および RespondToAuthChallengeAPIオペレーションの詳細については、APIドキュメントを参照してください。

組み込みの認証フローとチャレンジ

Amazon Cognito には、標準認証フローが Secure Remote Password (SRP) プロトコルを使用してユーザー名とパスワードを検証できるように、 AuthFlowと ChallengeName値が組み込まれています。 AWS SDKs には、Amazon Cognito によるこれらのフローのサポートが組み込まれています。

フローは USER_SRP_AUTH を AuthFlow として InitiateAuth に送信することから始まります。また、AuthParameters の USERNAME および SRP_A の値を送信します。InitiateAuth コールが成功した時点で、レスポンスのチャレンジパラメータには PASSWORD_VERIFIER が ChallengeName および SRP_B として含められています。次に、アプリは RespondToAuthChallenge を呼び出します。この呼び出しには PASSWORD_VERIFIER ChallengeName と、ChallengeResponses の必要なパラメータが使用されます。RespondToAuthChallenge の呼び出しが成功し、ユーザーのサインインが受け入れられると、Amazon Cognito によりトークンが発行されます。ユーザーの多要素認証 (MFA) を有効にした場合、Amazon Cognito は ChallengeNameのを返しますSMS_MFA。アプリは、RespondToAuthChallenge への別の呼び出しを通じて、必要なコードを提供できます。

カスタム認証フローとチャレンジ

アプリはカスタム認証フローを開始するために、InitiateAuth を CUSTOM_AUTH として Authflow を呼び出すことができます。カスタム認証フローで、3 つの Lambda トリガーがチャレンジとレスポンスの検証を制御します。

DefineAuthChallenge Lambda トリガーは、以前のチャレンジとレスポンスのセッション配列を入力として使用します。そして、次のチャレンジ名と、ユーザーが認証済みで、トークンを付与できるかどうかを示すブール値を生成します。この Lambda トリガーは、チャレンジを通じてユーザーのパスを制御するステートマシンです。
CreateAuthChallenge Lambda トリガーは、チャレンジ名を入力として使用し、チャレンジとパラメータを生成してレスポンスを評価します。DefineAuthChallenge が次のチャレンジとして CUSTOM_CHALLENGE を返すと、認証フローは、CreateAuthChallenge を呼び出します。CreateAuthChallengeLambda トリガーは、チャレンジメタデータパラメータで次のタイプのチャレンジを渡します。
VerifyAuthChallengeResponse Lambda 関数は、レスポンスを評価し、レスポンスが有効であるかどうかを示すブール値を返します。

カスタム認証フローでは、SRPパスワードの検証や MFAによるなどの組み込みチャレンジを組み合わせて使用することもできますSMS。CAPTCHA やシークレット質問などのカスタムチャレンジを使用できます。

カスタム認証フローでSRPパスワード検証を使用する

カスタム認証フローSRPにを含める場合は、で始める必要がありますSRP。

カスタムフローでSRPパスワード検証を開始するには、アプリは InitiateAuth を CUSTOM_AUTHとして呼び出しますAuthflow。AuthParameters マップでは、アプリからのリクエストには SRP_A: (SRPA 値) とが含まれますCHALLENGE_NAME: SRP_A。
CUSTOM_AUTH フローは、challengeName: SRP_A および challengeResult: true の初期セッションにより、DefineAuthChallenge の Lambda トリガーを呼び出します。Lambda 関数は、challengeName: PASSWORD_VERIFIER、issueTokens: false、および failAuthentication: false により、応答します。
次に、アプリは RespondToAuthChallenge challengeName: PASSWORD_VERIFIERを呼び出し、challengeResponsesマップSRPでに必要な他のパラメータを呼び出す必要があります。
Amazon Cognito がパスワードを検証すると、challengeName: PASSWORD_VERIFIER と challengeResult: true の 2 番目のセッションで、RespondToAuthChallenge により Lambda トリガーの DefineAuthChallenge が呼び出されます。その時点で DefineAuthChallenge Lambda トリガーは、challengeName: CUSTOM_CHALLENGE を使用して応答することでカスタムチャレンジを開始します。
MFA がユーザーに対して有効になっている場合、Amazon Cognito がパスワードを検証すると、ユーザーはでセットアップまたはサインインするように求められますMFA。

注記

Amazon Cognito がホストするサインインウェブページは、カスタム認証チャレンジの Lambda トリガーをアクティブ化できません。

サンプルコードを含めた Lambda トリガーの詳細については、「Lambda トリガーを使用したユーザープールワークフローのカスタマイズ」を参照してください。

管理認証フロー

認証のベストプラクティスは、カスタム認証フローで説明されているAPIオペレーションを使用してSRPパスワードを検証することです。そのアプローチ AWS SDKsを使用し、このアプローチはを使用するのに役立ちますSRP。ただし、SRP計算を回避したい場合は、安全なバックエンドサーバーに代替の管理APIオペレーションセットを使用できます。これらバックエンド管理の実装では、InitiateAuth の代わりに AdminInitiateAuth を使用します。同時に、RespondToAuthChallenge の代わりには AdminRespondToAuthChallenge を使用します。パスワードをプレーンテキストとして送信できるため、これらのオペレーションを使用する際にSRP計算を行う必要はありません。以下がその例です。


AdminInitiateAuth Request {
    "AuthFlow":"ADMIN_USER_PASSWORD_AUTH",
    "AuthParameters":{
        "USERNAME":"<username>",
        "PASSWORD":"<password>"
        },
    "ClientId":"<clientId>",
    "UserPoolId":"<userPoolId>"
}

これらの管理認証オペレーションには、開発者の認証情報が必要であり、 AWS Signature Version 4 (SigV4) の署名プロセスが使用されます。これらのオペレーションはSDKs、Lambda 関数に便利な Node.js を含む標準 AWS で使用できます。これらのオペレーションを使用し、同時にパスワードをプレーンテキストで受け入れるには、コンソールでそれらをアプリケーション向けに有効化する必要があります。または、ADMIN_USER_PASSWORD_AUTH または ExplicitAuthFlow への呼び出しで CreateUserPoolClient をUpdateUserPoolClient パラメータに渡すことができます。InitiateAuth および RespondToAuthChallenge オペレーションでは、ADMIN_USER_PASSWORD_AUTH AuthFlow は受け入れられません。

AdminInitiateAuth からのレスポンス ChallengeParameters では、USER_ID_FOR_SRP 属性 (存在する場合) に、ユーザーのエイリアス (E メールアドレスや電話番号など) ではなく、実際のユーザー名が含まれています。AdminRespondToAuthChallenge への呼び出しの ChallengeResponses では、このユーザー名を USERNAME パラメータで渡す必要があります。

注記

バックエンド管理者実装は、管理者認証フローを使用しているため、フローはデバイス追跡をサポートしていません。デバイス追跡が有効にしている場合、管理者認証は成功しますが、アクセストークンの更新に関する呼び出しはいずれも失敗します。

ユーザー移行の認証フロー

ユーザー移行用 Lambda トリガーは、レガシーのユーザー管理システムからユーザープールにユーザーを移行する際に役立ちます。USER_PASSWORD_AUTH 認証フローを選択している場合には、移行中のユーザーがパスワードをリセットする必要はありません。このフローは、認証中に暗号化されたSSL接続を介してユーザーのパスワードをサービスに送信します。

すべてのユーザーを移行したら、フローをより安全なSRPフローに切り替えます。SRP フローはネットワーク経由でパスワードを送信しません。

Lambda トリガーの詳細については、「Lambda トリガーを使用したユーザープールワークフローのカスタマイズ」を参照してください。

Lambda トリガーを使用したユーザーの移行の詳細については、「ユーザー移行の Lambda トリガーを使用したユーザーのインポート」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

認証

アプリクライアント