「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」
ユーザープール認証フロー
最新の認証フローはユーザーのアイデンティティを検証するため、パスワードの他に新しいチャレンジタイプを組み込んでいます。当社では、認証を 2 つの一般的なステップに類型化し、これらを
InitiateAuth
と RespondToAuthChallenge
の 2 つの API オペレーションで実装します。
認証が失敗するかユーザーがトークンを発行するまで、ユーザーは連続するチャレンジに応答することで認証します。異なるチャレンジを含むようにするため繰り返すことができる、これら 2 つのステップを使用してカスタム認証フローをサポートします。

AWS Lambda トリガーを使用して認証フローをカスタマイズできます。トリガーは独自のチャレンジを認証フローの一部として発行し検証を行います。
安全なバックエンドサーバー用として、管理者の認証フローを使用することもできます。ユーザー移行の認証フローを使用すると、ユーザーがパスワードをリセットしなくてもユーザー移行を許可できます。
サインインの試行の失敗は 5 回まで許容されます。その後は、一時的なロックアウトが開始されます。最初のロックアウト時間は 1 秒から始まり、試行が失敗するたびに時間が倍増され、最終的に約 15 分までロックアウトされます。一時的なロックアウト時間中の試行は無視されます。一時的なロックアウト時間の後で、次の試行が失敗すると、新しい一時的なロックアウトが前回の 2 倍の時間で開始されます。試行せずに約 15 分待つと、一時的なロックアウトもリセットされます。この対応は変更される場合があることに注意してください。
トピック
クライアント側の認証フロー
次に、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 トリガーを使用したユーザープールへのユーザーのインポート」を参照してください。