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

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

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

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

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

トピック

クライアント側の認証フロー
サーバー側の認証フロー
カスタム認証フロー
管理認証フロー
ユーザー移行の認証フロー

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

次に、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 管理者の認証情報が必要になります。

特に有効にするため、次の 1 つを実行していない限り AdminInitiateAuth と AdminRespondToAuthChallenge API が管理者サインインにユーザー名とパスワードのユーザー認証情報を許可することはできません。

サーバー側のアプリの CreateUserPoolClient または UpdateUserPoolClient の呼び出しで、ExplicitAuthFlow パラメータに ADMIN_NO_SRP_AUTHENTICATION を渡します。
[ユーザープールを作成する] の [アプリクライアント] タブで、[サーバーベースの認証でサインイン API を有効にする (ADMIN_NO_SRP_AUTH)] を選択します。詳細については、「ユーザープールのアプリクライアントの設定」を参照してください。

カスタム認証フロー

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

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

ユーザーがサインインしている場合は ID トークン、アクセストークン、および更新トークン
ユーザーのチャレンジに加えてセッションおよびパラメーター
ユーザーが認証に失敗した場合はエラー

Amazon Cognito がチャレンジを使用して InitiateAuth に返答すると、アプリはより多くの入力を取得して RespondToAuthChallenge API を呼び出し、チャレンジレスポンスを提供してセッションをパスバックします。Amazon Cognito は、InitiateAuth コール時と同じように RespondToAuthChallenge コールに返答して、ユーザーがサインインしている場合にはトークン、または別のチャレンジあるいはエラーを返します。別のチャレンジが返された場合、ユーザーがサインインするかエラーが返されるまで、RespondToAuthChallenge を呼び出すアプリによってシーケンスが繰り返されます。詳細については、InitiateAuth API と RespondToAuthChallenge API の API ドキュメントを参照してください。

Amazon Cognito には、標準認証フローで Secure Remote Password (SRP) プロトコルを通じてユーザー名とパスワードを検証するための組み込みの AuthFlow 値と ChallengeName 値がいくつかあります。このフローは、iOS、Android、および Amazon Cognito 用の JavaScript SDK に組み込まれています。フローの概要を説明すると、まず USER_SRP_AUTH を AuthFlow として InitiateAuth に送信します。同時に、AuthParameters に USERNAME 値と SRP_A 値を指定します。InitiateAuth 呼び出しに成功した場合、レスポンスのチャレンジパラメーターには PASSWORD_VERIFIER が ChallengeName および SRP_B として含められます。次に、アプリが ChallengeResponses で PASSWORD_VERIFIER ChallengeName と必要なパラメーターを使用して RespondToAuthChallenge を呼び出します。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 関数は、レスポンスを評価し、レスポンスが有効であったかどうかを示すブール値を返します。

カスタム認証フローでは、SMS による SRP パスワードの確認や MFA などの組み込みチャレンジと、CAPTCHA または秘密の質問などのカスタムチャレンジの組み合わせを使用することもできます。カスタム認証フローに SRP を含める場合、SRP から始める必要があります。SRP パスワードの確認を開始した場合、DefineAuthChallenge Lambda トリガーが SRP_A をチャレンジ名として返し、認証パラメーターマップで SRP_A を使用します。パスワードが確認されると、前のチャレンジ配列の PASSWORD_VERIFIER を使用して DefineAuthChallenge Lambda トリガーが再度呼び出されます。MFA は、ユーザーに対して有効になっている場合、自動的に実行されます。

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

注記

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

管理認証フロー

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


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

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

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

注記

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

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

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

すべてのユーザー移行が完了したら、ネットワーク経由でパスワードが送信されないセキュアリモートパスワード (SRP) プロトコルに切り替えることをお勧めします。

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

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

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

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

ドキュメントの表記規則

« 前次 »