Это обходной путь, пока Cognito не включит эту информацию в событие, переданное для запуска. Настройте различные правила для расширенных функций безопасности на основе идентификатора клиента приложения. Для идентификатора клиента приложения 1 настройте адаптивную аутентификацию, чтобы запретить пользователям вход в систему при обнаружении риска. А для идентификатора клиента приложения 2 сконфигурируйте его так, чтобы он всегда разрешал вход в систему.
В лямбде настраиваемого триггера аутентификации решайте проблемы на основе идентификатора клиента приложения. Поэтому, когда клиент приложения равен 1, используйте обычные проблемы входа в систему. И когда идентификатор клиента приложения равен 2, отправьте дополнительные вызовы клиенту. Клиент должен войти в систему с идентификатором клиента приложения 1, и если он не сможет войти по причине Unable to login because of security reasons, то войдите в систему с идентификатором клиента приложения 2.
К сожалению, Cognito не имеет отдельных кодов ошибок, поэтому пришлось искать строку ошибки в ответе. Этот подход требует от клиента, чей запрос считается рискованным, сделать второй запрос cognito. Это займет больше времени для этого клиента, но, по крайней мере, большинство пользователей не увидят более медленных входов в систему.
Один вариант, который был исследован и опущен, заключался в использовании API-интерфейса администратора Cognito из lambda. Есть две проблемы с этим. Во-первых, каждый дополнительный вход в систему будет замедлен этим дополнительным http-запросом к Cognito. Во-вторых, Вы можете получить последние n событий, но нет способа гарантировать, что мы запрашиваем правильное событие. В случае одновременных попыток входа в систему, 1 без риска и 1 высокого риска, и admin api возвращает отсутствие риска как последнее событие, тогда оба входа будут проходить без риска.