Итак, моя ошибка заключалась в том, что я не учитывал пользовательский процесс аутентификации. Я нашел другую документацию, которая, кстати, должна определенно использоваться:
Настройка потока аутентификации пула пользователей
Я столкнулся с 2 неправильными частями в документация здесь (подстраницы триггеров) и 1 ошибка с моей стороны.
Неправильная часть 1: входные данные DefineAuthChallenge и CreateAuthChallenge для сеанса определены как список результатов испытаний. Это все нормально, но объект результата запроса имеет неправильно отображаемую часть метаданных вызова, которая записывается так: «ChallengeMetaData», когда вместо этого должно быть «ChallengeMetadata», с строчным «d» вместо «data» вместо «data» верхний регистр один. Это дало мне ошибку «Нераспознанный лямбда-вывод», потому что «ChallengeMetaData» не был тем, чего ожидал сервер, он искал «ChallengeMetadata», которого не было. Когда вы в первый раз вводите лямбду define auth challenge, эта ошибка не отображается, потому что сеанс не содержит ответов на вызов. Однако, как только вы подтвердите вызов, он заполняется, и заглавная буква d доставляет вам неприятности.
Неправильная часть 2: Как описано в моем вопросе, вход VerifyAuthChallenge для «challengeAnswer» - это строка, а не словарь.
Все эти неправильные части правильно отображаются на первой странице документации, на которую я ссылаюсь здесь. Поэтому я бы рекомендовал использовать это вместо другой документации.
Ошибка на моей стороне: я действительно не проверял, что происходит после того, как вы проверите пользовательский вызов с помощью триггера VerifyAuthChallenge. В приведенной ссылке на изображении над заголовком «Лямбда-триггер DefineAuthChallenge: задачи (конечный автомат)» четко указано, что после проверки ответа снова запускается триггер DefineAuthChallenge, который я не рассматривал. [118 ]
Я надеюсь, что смогу сэкономить кому-то время, которое понадобилось мне, чтобы разобраться с этим: -)