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

Userプール認証フロー

最新の認証フローはユーザーのアイデンティティを検証するため、パスワードの他に新しいチャレンジタイプを組み込んでいます。AWS は認証を 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 を使用できます。

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

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

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

サーバー側のアプリによる CreateUserPoolClient または UpdateUserPoolClient への呼び出しの ExplicitAuthFlow パラメータに ADMIN_USER_PASSWORD_AUTH (以前は ADMIN_NO_SRP_AUTH と呼ばれていたもの) を渡す。
[Create a user pool] (ユーザープールを作成する) の [App clients] (アプリクライアント) タブで 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 は、InitiateAuth コールの場合と同様に RespondToAuthChallenge コールに応答し、トークン (ユーザーがサインインされた場合)、別のチャレンジ、またはエラーを提供します。別のチャレンジが返された場合、ユーザーがサインイン済みになるかエラーが返されるまで、アプリが RespondToAuthChallenge を呼び出すシーケンスが繰り返されます。詳細は、InitiateAuth API 操作と RespondToAuthChallenge API 操作に関する API ドキュメントに記載されています。

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

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

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

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

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

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

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

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

カスタムフローで SRP パスワードの検証を開始する場合、アプリは InitiateAuth を CUSTOM_AUTH として Authflow を呼び出します。これは、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 がホストするサインインウェブページは、カスタム認証フローをサポートしていません。

管理認証フロー

推奨される認証アプローチは、カスタム認証フローで説明されている API 操作と、パスワード検証のための SRP の併用です。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) の署名プロセスが使用されます。これらの操作は、Lambda 関数での使用に便利な標準 AWS SDK (Node.js を含む) で使用できます。これらの操作でパスワードをプレーンテキストで受け入れるには、それをコンソールでアプリ用に有効にする必要があります。または、ADMIN_USER_PASSWORD_AUTH または ExplicitAuthFlow への呼び出しで CreateUserPoolClient をUpdateUserPoolClient パラメータに渡すことができます。ADMIN_USER_PASSWORD_AUTH 操作と AuthFlow 操作では、InitiateAuth RespondToAuthChallenge が受け入れられません。

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

注記

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

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

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

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

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

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

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

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

ドキュメントの表記規則

認証

ロギングとモニタリング