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

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

最新の認証フローはユーザーのアイデンティティを検証するため、パスワードの他に新しいチャレンジタイプを組み込んでいます。当社では、認証を 2 つの一般的なステップに類型化し、これらを InitiateAuth と RespondToAuthChallenge の 2 つの API オペレーションで実装します。

認証が失敗するかユーザーがトークンを発行するまで、ユーザーは連続するチャレンジに応答することで認証します。異なるチャレンジを含むようにするため繰り返すことができる、これら 2 つのステップを使用してカスタム認証フローをサポートします。

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

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

注記

サインインの試行の失敗は 5 回まで許容されます。その後は、一時的なロックアウトが開始されます。最初のロックアウト時間は 1 秒から始まり、試行が失敗するたびに時間が倍増され、最終的に約 15 分までロックアウトされます。一時的なロックアウト時間中の試行は無視されます。一時的なロックアウト時間の後で、次の試行が失敗すると、新しい一時的なロックアウトが前回の 2 倍の時間で開始されます。試行せずに約 15 分待つと、一時的なロックアウトもリセットされます。この対応は変更される場合があることに注意してください。

トピック

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

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

次に、AWS Mobile SDK for Android、AWS Mobile SDK for iOS、AWS SDK for JavaScript のいずれかで作成したエンドユーザーのクライアント側のアプリで、どのようにユーザープール認証が行われるのかを説明します。

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

メソッドが認証パラメーターを返します。

注記

Android、iOS、JavaScript SDK の Amazon Cognito SRP サポートを使用して、アプリが SRP の詳細を生成します。
アプリは RespondToAuthChallenge オペレーションを呼び出します。呼び出しが成功すると、ユーザーのトークンが返され、認証フローが完了します。

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

サーバー側の認証フロー

エンドユーザーのアプリはないが、代わりに Java、Ruby、Node.js のいずれかの安全なバックエンドまたはサーバー側のアプリを使用している場合は、Amazon Cognito ユーザープールの認証済みのサーバー側 API を使用できます。

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

サーバー側のアプリは、AdminInitiateAuth API オペレーションを (InitiateAuth の代わりに) 呼び出します。このオペレーションには AWS 管理者の認証情報が必要です。このオペレーションは、認証パラメータを返します。
アプリは、認証パラメータを取得すると、AdminRespondToAuthChallenge API オペレーションを (RespondToAuthChallenge の代わりに) 呼び出します。このオペレーションにも AWS 管理者の認証情報が必要です。

AdminInitiateAuth オペレーションと AdminRespondToAuthChallenge オペレーションでは、ユーザー名とパスワードのユーザー認証情報を管理者のログインに使用することを許可しません。ただし、次のいずれかを実行して明示的にユーザー認証情報を使用可能にした場合を除きます。

サーバー側のアプリによる CreateUserPoolClient または UpdateUserPoolClient への呼び出しで、ExplicitAuthFlow パラメータに ADMIN_USER_PASSWORD_AUTH (以前は ADMIN_NO_SRP_AUTH と呼ばれていました) を渡します。
[アプリクライアント] タブの [ユーザープールを作成する] で [Enable sign-in API for server-based authentication (ADMIN_USER_PASSWORD_AUTH)] を選択します。詳細については、「ユーザープールのアプリクライアントの設定」を参照してください。

カスタム認証フロー

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

カスタム認証フローは、さまざまな要件に合わせたカスタマイズ可能な一連のチャレンジおよびレスポンスサイクルを許可するように設計されています。このフローは、使用される認証のタイプを示し、初期認証パラメータを指定する InitiateAuth API オペレーションの呼び出しから始まります。Amazon Cognito は InitiateAuth コールに対して次のいずれかで応答します。

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

Amazon Cognito が InitiateAuth コールに対してチャレンジで応答すると、アプリはより多くの入力を収集し、RespondToAuthChallenge オペレーションを呼び出してチャレンジのレスポンスを返し、セッションを渡します。Amazon Cognito は RespondToAuthChallenge コールに対して、InitiateAuth コールに対する場合と同様に応答し、トークン (ユーザーがサインイン済みの場合)、別のチャレンジ、エラーのいずれかを返します。別のチャレンジが返された場合、ユーザーがサインイン済みになるかエラーが返されるまで、アプリが RespondToAuthChallenge を呼び出すシーケンスが繰り返されます。詳細については、API ドキュメントで InitiateAuth API オペレーションと RespondToAuthChallenge API オペレーションを参照してください。

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

Amazon Cognito には、標準の認証フロー用として AuthFlow と ChallengeName のいくつかの値が組み込まれています。これらにより、Secure Remote Password (SRP) プロトコルを通じてユーザー名とパスワードを検証します。このフローは、iOS、Android、および Amazon Cognito 用の JavaScript SDK に組み込まれています。フローを要約すると、まず USER_SRP_AUTH を AuthFlow として InitiateAuth に送信します。同時に、USERNAME 値と SRP_A 値を AuthParameters に渡します。InitiateAuth コールが成功すると、レスポンスのチャレンジパラメータに PASSWORD_VERIFIER が ChallengeName および SRP_B として含められます。次に、アプリは RespondToAuthChallenge を呼び出します。この呼び出しには PASSWORD_VERIFIER ChallengeName と、ChallengeResponses の必要なパラメータが使用されます。RespondToAuthChallenge の呼び出しに成功し、ユーザーがサインイン済みになると、トークンが返されます。ユーザーの Multi-Factor Authentication (MFA) が有効な場合は、SMS_MFA の ChallengeName が返され、アプリは RespondToAuthChallenge をもう一度呼び出して必要なコードを指定できます。

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

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

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

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

カスタム認証フローにおける SRP パスワードの検証の使用

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

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

注記

Amazon Cognito がホストするサインインウェブページは、カスタム認証フローをサポートしていません。

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

注記

Amazon Cognito でホストされたサインインウェブページは、カスタム認証フローをサポートしていません。

管理認証フロー

推奨される認証アプローチは、パスワードの検証に SRP を使用するように、API オペレーションで記述されたカスタム認証フローです。iOS、Android、および JavaScript SDK は、そのアプローチに基づいており、SRP を簡単に使用できます。ただし、SRP 計算を回避する場合は、セキュアなバックエンドサーバー用に設計された管理 API オペレーションの代替セットがあります。これらのバックエンド管理実装では、AdminInitiateAuth が InitiateAuth の代わりに使用され、AdminRespondToAuthChallenge が RespondToAuthChallenge の代わりに使用されます。これらのオペレーションを使用すると、パスワードをプレーンテキストとして送信できるため、SRP 計算は必要ありません。例を示します。


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

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

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

注記

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

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

ユーザー移行 Lambda トリガーを使用すると、レガシーのユーザー管理システムからユーザープールにユーザーを簡単に移行できます。ユーザーの移行中にユーザーがパスワードをリセットしないようにするには、USER_PASSWORD_AUTH 認証フローを選択します。このフローは、認証中に暗号化された SSL 接続を介してユーザーのパスワードをサービスに送信します。

すべてのユーザーの移行が完了したら、フローをよりセキュアな SRP フローに切り替えることをお勧めします。SRP フローは、ネットワーク経由でパスワードを送信しません。

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

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

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

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

ドキュメントの表記規則

認証

ログ記録とモニタリング