Пользовательский поток аутентификации AWS Cognito с USER_PASSWORD_AUTH

Question

В настоящее время я работаю над настраиваемым потоком аутентификации, используя триггеры определения, создания и проверки. Однако пароль пользователя не проверяется во время потока. Мы используем опцию USER_PASSWORD_AUTH на наших клиентах, поэтому нет SRP.

Я видел этот вопрос Могу ли я использовать триггер миграции в пользовательском потоке аутентификации и не совсем понял, ответил ли он на мой вопрос:

Можно ли использовать пользовательский поток аутентификации в сочетании с потоком имя пользователя-пароль (не SRP)? И если да, то какое имя для вызова мне нужно вернуть?

Здесь указано, что комбинации могут использоваться, но мне кажется, что PASSWORD_VERIFIER работает только с аутентификацией SRP:

Пользовательский поток аутентификации может также использовать комбинацию встроенных задач, таких как проверка пароля SRP и MFA с помощью SMS, и пользовательских задач, таких как CAPTCHA или секретные вопросы.

Answer 1

Итак, мне удалось добавить запрос пароля в пользовательский поток аутентификации, вернув его в качестве первого вызова в лямбда-триггере DefineAuthChallenge, например:

// Add the password verifier to verify the password first.
if (input.Request?.Session == null || !input.Request.Session.Any(s => s.ChallengeName == "PASSWORD_VERIFIER"))
{
    input.Response.ChallengeName = AuthChallengeNames.AWS_PasswordVerifier;
    input.Response.FailAuthentication = false;
    input.Response.IssueTokens = false;

    return input;
}

Никаких проблем в сеансе не дается, так как это должен быть первый вызов, который будет возвращен пользовательским потоком аутентификации, как описано здесь (раздел «Поток пользовательской аутентификации»):

Если вы хотите включить SRP в пользовательский поток аутентификации, вам нужно начать с него.

Однако, в настоящий момент, если пользователь вынужден сменить свой пароль, пользовательский поток аутентификации впоследствии пропускается, что на данный момент является ошибкой, подтвержденной AWS. Смотрите похожие сообщения здесь .

Пример здесь (раздел «Пример определения проверки подлинности») оказался явно ошибочным, поскольку в первый раз при вызове триггера определения проверки подлинности не возникает никаких проблем.