Custom authentication challenge Lambda triggers - Amazon Cognito
SRP 認証

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Custom authentication challenge Lambda triggers

Amazon Cognito ユーザープールの認証フローを構築した後で、組み込みフローを超えた認証モデルに拡張したい場合があります。カスタムチャレンジトリガーの一般的なユースケースの 1 つは、ユーザー名、パスワード、および多要素認証 (MFA) を超えた追加のセキュリティチェックを実装することです。カスタムチャレンジは、Lambda がサポートするプログラミング言語で生成できる質問とレスポンスです。例えば、認証を許可する前に、CAPTCHA を解決することや、セキュリティの質問に回答することをユーザーに要求する場合があります。もう 1 つの潜在的なニーズは、特殊な認証要素やデバイスと統合することです。または、ハードウェアセキュリティキーまたは生体認証デバイスでユーザーを認証するソフトウェアを開発済みである場合もあります。カスタムチャレンジの認証成功の定義は、どのような回答であっても、Lambda 関数が正しいものとして受け入れる回答です。例えば、固定文字列、または外部 API からの十分なレスポンスです。

カスタムチャレンジを使用した認証を開始して認証プロセスを完全に制御することも、アプリケーションがカスタムチャレンジを受信する前にユーザー名パスワード認証を実行することもできます。

カスタム認証チャレンジの Lambda トリガー

定義

チャレンジシーケンスを開始します。新しいチャレンジを開始するか、認証を完了としてマークするか、認証の試行を停止するかを決定します。

作成

ユーザーが回答する必要がある質問をアプリケーションに発行します。この関数は、アプリケーションがユーザーに表示するセキュリティの質問や CAPTCHA へのリンクを提示する場合があります。

検証

予想される回答を把握し、それをチャレンジレスポンスでアプリケーションが提供する回答と比較します。この関数は、CAPTCHA サービスの API を呼び出して、ユーザーの試行したソリューションの期待される結果を取得することができます。

これらの 3 つの Lambda 関数は連鎖して、完全に制御範囲内で独自の設計の認証メカニズムを提示します。カスタム認証にはクライアントと Lambda 関数でアプリケーションロジックが必要なため、マネージドログイン内でカスタム認証を処理できません。この認証システムには、デベロッパーの労力が追加で必要です。アプリケーションは、ユーザープール API を使用して認証フローを実行し、カスタム認証チャレンジの中心に質問をレンダリングするカスタムビルドのログインインターフェイスを使用して、結果として生じるチャレンジを処理する必要があります。

チャレンジの Lambda トリガー

カスタム認証の実装の詳細については、「カスタム認証フローとチャレンジ」を参照してください。

API オペレーション InitiateAuth または AdminInitiateAuth と RespondToAuthChallenge または AdminRespondToAuthChallenge 間の認証。このフローでは、認証が失敗するか、トークンが発行されるまで、ユーザーは引き続きチャレンジに回答して認証を行います。チャレンジレスポンスが新しいチャレンジとなる場合があります。この場合、アプリケーションは新しいチャレンジに対して必要な回数を応答します。認証は、認証チャレンジの定義関数がそれまでの結果を分析し、すべてのチャレンジが回答されたと判断し、IssueTokens を返すときに完了します。

トピック

カスタムチャレンジフローでの SRP 認証

Amazon Cognito では、カスタムチャレンジを発行する前にユーザーパスワードを検証させることができます。リクエストレートクォータの認証カテゴリに関連付けられているすべての Lambda トリガーは、カスタムチャレンジフローで SRP 認証を行うと、実行されます。以下は、そのプロセスの概要です。

  1. アプリは、AuthParameters マップを使用して InitiateAuth または AdminInitiateAuth を呼び出してサインインを開始します。パラメータには CHALLENGE_NAME: SRP_A,、SRP_A および USERNAME の値を含める必要があります。

  2. Amazon Cognito は、challengeName: SRP_A と challengeResult: true を含む初期セッションで、認証チャレンジの定義 Lambda トリガーを呼び出します。

  3. Lambda 関数は、これらの入力を受け取った後、challengeName: PASSWORD_VERIFIER、issueTokens: false、failAuthentication: false で応答します。

  4. パスワードの検証が成功すると、Amazon Cognito challengeName: PASSWORD_VERIFIER と challengeResult: true が含まれる新しいセッションで Lambda 関数を再度呼び出します。

  5. カスタムチャレンジを開始するために、Lambda 関数は challengeName: CUSTOM_CHALLENGE、issueTokens: false、および failAuthentication: false で応答します。パスワード検証でカスタム認証フローを開始したくない場合は、CHALLENGE_NAME: CUSTOM_CHALLENGE を含む AuthParameters マップでサインインを開始できます。

  6. チャレンジループは、すべてのチャレンジが回答されるまで繰り返します。

以下は、SRP フローによるカスタム認証の前になされる開始 InitiateAuth リクエストの例です。

{
    "AuthFlow": "CUSTOM_AUTH",
    "ClientId": "1example23456789",
    "AuthParameters": {
        "CHALLENGE_NAME": "SRP_A",
        "USERNAME": "testuser",
        "SRP_A": "[SRP_A]",
        "SECRET_HASH": "[secret hash]"
    }
}

カスタム認証 SRP フローでのパスワードのリセット

ユーザーが FORCE_CHANGE_PASSWORDステータスの場合、カスタム認証フローは、認証チャレンジの整合性を維持しながら、パスワード変更ステップを統合する必要があります。Amazon Cognito は、NEW_PASSWORD_REQUIREDチャレンジ中に認証チャレンジの定義 Lambda トリガーを呼び出します。このシナリオでは、カスタムチャレンジフローと SRP 認証を使用してサインインするユーザーがパスワードリセット状態にある場合、新しいパスワードを設定できます。

ユーザーが RESET_REQUIREDまたは FORCE_CHANGE_PASSWORDステータスの場合、 でNEW_PASSWORD_REQUIREDチャレンジに応答する必要がありますNEW_PASSWORD。SRP を使用したカスタム認証では、Amazon Cognito はユーザーが SRP NEW_PASSWORD_REQUIREDチャレンジを完了した後にPASSWORD_VERIFIERチャレンジを返します。認証チャレンジ定義トリガーは、 session配列で両方のチャレンジ結果を受け取り、ユーザーがパスワードを正常に変更した後、追加のカスタムチャレンジを続行できます。

認証チャレンジの定義 Lambda トリガーは、SRP 認証、パスワードリセット、およびその後のカスタムチャレンジを通じてチャレンジシーケンスを管理する必要があります。トリガーは、 PASSWORD_VERIFIER および NEW_PASSWORD_REQUIRED結果の両方を含む、 sessionパラメータで完了したチャレンジの配列を受け取ります。実装例については、「」を参照してください認証チャレンジの定義の例。

認証フローのステップ

カスタムチャレンジの前にパスワードを検証する必要があるユーザーの場合、このプロセスは次のステップに従います。

  1. アプリは、AuthParameters マップを使用して InitiateAuth または AdminInitiateAuth を呼び出してサインインを開始します。パラメータには、CHALLENGE_NAME: SRP_A、、および SRP_Aの値を含める必要がありますUSERNAME。

  2. Amazon Cognito は、challengeName: SRP_A と challengeResult: true を含む初期セッションで、認証チャレンジの定義 Lambda トリガーを呼び出します。

  3. Lambda 関数は、これらの入力を受け取った後、challengeName: PASSWORD_VERIFIER、issueTokens: false、failAuthentication: false で応答します。

  4. パスワードの検証が成功すると、次の 2 つのことのいずれかが発生します。

    通常のステータスのユーザーの場合:

    Amazon Cognito は、 challengeName: PASSWORD_VERIFIERと を含む新しいセッションで Lambda 関数を再度呼び出しますchallengeResult: true。

    カスタムチャレンジを開始するために、Lambda 関数は challengeName: CUSTOM_CHALLENGE、issueTokens: false、および failAuthentication: false で応答します。

    RESET_REQUIRED または FORCE_CHANGE_PASSWORDステータスのユーザーの場合:

    Amazon Cognito は、 challengeName: PASSWORD_VERIFIERと を含むセッションで Lambda 関数を呼び出しますchallengeResult: true。

    Lambda 関数は、challengeName: NEW_PASSWORD_REQUIRED、issueTokens: false、および failAuthentication: false により、これに応答する必要があります。

    パスワードが正常に変更されると、Amazon Cognito は PASSWORD_VERIFIERと NEW_PASSWORD_REQUIRED の結果の両方を含むセッションで Lambda 関数を呼び出します。

    カスタムチャレンジを開始するために、Lambda 関数は challengeName: CUSTOM_CHALLENGE、issueTokens: false、および failAuthentication: false で応答します。

  5. チャレンジループは、すべてのチャレンジが回答されるまで繰り返します。

パスワード検証でカスタム認証フローを開始したくない場合は、CHALLENGE_NAME: CUSTOM_CHALLENGE を含む AuthParameters マップでサインインを開始できます。

セッション管理

認証フローは、一連のセッション IDs とチャレンジ結果を通じてセッションの継続性を維持します。各チャレンジレスポンスは、セッションの再利用エラーを防ぐために新しいセッション ID を生成します。これは、多要素認証フローにとって特に重要です。

チャレンジ結果は、Lambda トリガーが受信するセッション配列に時系列的に保存されます。FORCE_CHANGE_PASSWORD ステータスのユーザーの場合、セッション配列には以下が含まれます。

  1. session[0] - 初期SRP_Aチャレンジ

  2. session[1] - PASSWORD_VERIFIER結果

  3. session[2] - NEW_PASSWORD_REQUIRED結果

  4. 後続の要素 - 追加のカスタムチャレンジの結果

認証フローの例

次の例は、パスワード変更とカスタム CAPTCHA チャレンジの両方を完了する必要があるFORCE_CHANGE_PASSWORDステータスのユーザーの完全なカスタム認証フローを示しています。

  1. InitiateAuth リクエスト

    {
    "AuthFlow": "CUSTOM_AUTH",
    "ClientId": "1example23456789",
    "AuthParameters": {
        "CHALLENGE_NAME": "SRP_A",
        "USERNAME": "testuser",
        "SRP_A": "[SRP_A]"
    }
}

  2. InitiateAuth レスポンス

    {
    "ChallengeName": "PASSWORD_VERIFIER",
    "ChallengeParameters": {
        "USER_ID_FOR_SRP": "testuser"
    },
    "Session": "[session_id_1]"
}

  3. を使用した RespondToAuthChallenge リクエスト PASSWORD_VERIFIER

    {
    "ChallengeName": "PASSWORD_VERIFIER",
    "ClientId": "1example23456789",
    "ChallengeResponses": {
        "PASSWORD_CLAIM_SIGNATURE": "[claim_signature]",
        "PASSWORD_CLAIM_SECRET_BLOCK": "[secret_block]",
        "TIMESTAMP": "[timestamp]",
        "USERNAME": "testuser"
    },
    "Session": "[session_id_1]"
}

  4. NEW_PASSWORD_REQUIREDチャレンジを含む RespondToAuthChallenge レスポンス

    {
    "ChallengeName": "NEW_PASSWORD_REQUIRED",
    "ChallengeParameters": {},
    "Session": "[session_id_2]"
}

  5. を使用した RespondToAuthChallenge リクエスト NEW_PASSWORD_REQUIRED

    {
    "ChallengeName": "NEW_PASSWORD_REQUIRED",
    "ClientId": "1example23456789",
    "ChallengeResponses": {
        "NEW_PASSWORD": "[password]",
        "USERNAME": "testuser"
    },
    "Session": "[session_id_2]"
}

  6. CAPTCHA カスタムチャレンジによる RespondToAuthChallenge レスポンス

    {
    "ChallengeName": "CUSTOM_CHALLENGE",
    "ChallengeParameters": {
        "captchaUrl": "url/123.jpg"
    },
    "Session": "[session_id_3]"
}

  7. CAPTCHA カスタムチャレンジへの回答を含む RespondToAuthChallenge リクエスト

    {
    "ChallengeName": "CUSTOM_CHALLENGE",
    "ClientId": "1example23456789",
    "ChallengeResponses": {
        "ANSWER": "123",
        "USERNAME": "testuser"
    },
    "Session": "[session_id_3]"
}

6。最終成功レスポンス

{
    "AuthenticationResult": {
        "AccessToken": "eyJra456defEXAMPLE",
        "ExpiresIn": 3600,
        "IdToken": "eyJra789ghiEXAMPLE",
        "RefreshToken": "eyJjd123abcEXAMPLE",
        "TokenType": "Bearer"
    },
    "ChallengeParameters": {}
}