ユーザープール認証フロー - Amazon Cognito

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

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

  1. InitiateAuth

  2. RespondToAuthChallenge

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

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

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

注記

ユーザーは、適切なサインインに失敗し、Amazon Cognito に一時的にロックアウトされる前に、5 回までサインインを試みることができます。ロックアウト時間は 1 秒間から始まり、その後の試行が失敗するたびに倍増して指数関数的に増加し、最大で約 15 分になります。一時的なロックアウト中にログインを試みても、Amazon Cognito に無視されるため、その間は新しいロックアウト期間は開始されません。ユーザーが 15 分待つと、Amazon Cognito は一時的なロックアウトをリセットします。この動作は変更される可能性があります。

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

AWS Mobile SDK for Android、AWS Mobile SDK for iOS、または AWS SDK for JavaScript で作成したユーザークライアント側のアプリケーションの場合、以下の手順で動作します。

  1. ユーザーがアプリにユーザー名とパスワードを入力します。

  2. アプリケーションが、ユーザーのユーザー名と SRP (Secure Remote Password) 詳細を使用して、InitiateAuth オペレーションを呼び出します。

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

    注記

    アプリは、AWS SDK に組み込まれている Amazon Cognito SRP 機能を使用して SRP の詳細を生成します。

  3. アプリが RespondToAuthChallenge 操作を呼び出します。呼び出しが成功すると、Amazon Cognito からユーザーのトークンが返され、認証フローが完了します。

    Amazon Cognito に必要なチャレンジが別に存在する場合は、RespondToAuthChallenge を呼び出してもトークンは返されません。代わりに、呼び出しによってセッションが返されます。

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

サーバー側の認証フロー

ユーザーアプリがなく、その代わりに Java、Ruby、Node.js のセキュアバックエンド、またはサーバー側のアプリを使用する場合は、Amazon Cognito ユーザープールの認証済みのサーバー側 API を使用できます。

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

  • サーバー側のアプリは、InitiateAuth の代わりに AdminInitiateAuth API 操作を呼び出します。このオペレーションには AWS 管理者の認証情報が必要です。オペレーションからは、必要な認証パラメータが返されます。

  • サーバー側のアプリに認証パラメータが設定された後に、AdminRespondToAuthChallenge API オペレーションが (RespondToAuthChallenge の代わりに) 呼び出されます。AdminRespondToAuthChallenge API オペレーションは、AWS 管理者の認証情報を指定した場合のみ成功します。

AdminInitiateAuth および AdminRespondToAuthChallenge の API オペレーションでは、ユーザーネームとパスワードのユーザー認証情報を管理者のログインに使用することを許可しません。ただし、以下のいずれかの方法で、明示的にユーザー認証情報を使用可能にした場合を除きます。

  • 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 トリガーを使用したチャレンジ/レスポンスベースの認証モデルの作成に役立ちます。

注記

カスタム認証フローでアドバンストセキュリティ機能を使用することはできません。詳細については、「ユーザープールにアドバンストセキュリティを追加する」を参照してください。

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

  • ユーザーへのチャレンジ、ならびにセッションおよびパラメータ。

  • ユーザーが認証に失敗した場合はエラー。

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

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

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

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

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

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

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

  • DefineAuthChallenge Lambda トリガーは、以前のチャレンジとレスポンスのセッション配列を入力として使用します。そして、次のチャレンジ名と、ユーザーが認証済みで、トークンを付与できるかどうかを示すブール値を生成します。この Lambda トリガーは、チャレンジを通じてユーザーのパスを制御するステートマシンです。

  • CreateAuthChallenge Lambda トリガーは、チャレンジ名を入力として使用し、チャレンジとパラメータを生成してレスポンスを評価します。DefineAuthChallenge が次のチャレンジとして CUSTOM_CHALLENGE を返すと、認証フローは、CreateAuthChallenge を呼び出します。CreateAuthChallengeLambda トリガーは、チャレンジメタデータパラメータで次のタイプのチャレンジを渡します。

  • VerifyAuthChallengeResponse Lambda 関数は、レスポンスを評価し、レスポンスが有効であるかどうかを示すブール値を返します。

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

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

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

  • カスタムフローで SRP パスワードの検証を開始する場合、アプリは InitiateAuthCUSTOM_AUTH として Authflow を呼び出します。AuthParameters マップで、アプリケーションからのリクエストは、SRP_A: (SRP A 値) および CHALLENGE_NAME: SRP_A を含んでいます。

  • CUSTOM_AUTH フローは、challengeName: SRP_A および challengeResult: true の初期セッションにより、DefineAuthChallenge の Lambda トリガーを呼び出します。Lambda 関数は、challengeName: PASSWORD_VERIFIERissueTokens: false、および failAuthentication: false により、応答します。

  • 次にアプリケーションは、(challengeName: PASSWORD_VERIFIER、そして challengeResponses マップ内の SRP に必要な他のパラメータを使用して) RespondToAuthChallenge を呼び出す必要があります。

  • Amazon Cognito がパスワードを検証すると、challengeName: PASSWORD_VERIFIERchallengeResult: true の 2 番目のセッションで、RespondToAuthChallenge によりLambda トリガーの DefineAuthChallenge が呼び出されます。その時点で DefineAuthChallenge Lambda トリガーは、challengeName: CUSTOM_CHALLENGE を使用して応答することでカスタムチャレンジを開始します。

  • MFA がユーザーに対して有効になっている場合、Amazon Cognito がパスワードを確認した後、ユーザーは MFA の設定またはサインインを要求されます。

注記

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

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

管理認証フロー

認証のベストプラクティスは、カスタム認証フローで説明されている API オペレーションを (SRP でのパスワード検証とともに) 使用することです。AWSSDK はこのアプローチを使用します。このアプローチは 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 署名バージョン 4 (SigV4) の署名プロセスが使用されます。これらのオペレーションは、Lambda 関数にとって便利な、標準の AWS SDK (Node.js を含む) 内での使用が可能です。これらのオペレーションを使用し、同時にパスワードをプレーンテキストで受け入れるには、コンソールでそれらをアプリケーション向けに有効化する必要があります。または、ADMIN_USER_PASSWORD_AUTH または ExplicitAuthFlow への呼び出しで CreateUserPoolClientUpdateUserPoolClient パラメータに渡すことができます。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 トリガーを使用したユーザープールへのユーザーのインポート」を参照してください。