Я работаю над проектом с использованием AWS API Gateway в сочетании с AWS Cognito для аутентификации и авторизации пользователей. Я определил свой пул пользователей и добавил сервер ресурсов для добавления настраиваемых областей, в настоящее время у меня их две:
com.mycompany.api/lender.rcom.mycompany.api/lender.cudИспользуя Cognito, я создал клиент приложения, в котором настроен Authorization code grant Поток OAuth. Я разрешил свои пользовательские области, определенные выше. Я установил доменное имя для пула пользователей и в результате получил размещенный пользовательский интерфейс, который я могу использовать для регистрации / входа в систему и т. Д.
Я вижу, что это настраивается параметрами в URL-адресе, т.е.
https://mycompany.auth.eu-west-2.amazoncognito.com/login?client_id=<reacted-client-id>&response_type=code&scope=com.mycompany.api/lender.r&redirect_uri=https://foo.bar
Вопрос
Что мешает злоумышленнику добавить com.mycompany.api/lender.cud в список областей в URL? Это позволит им использовать действительный логин для добавления дополнительных областей к их токену доступа JWT, который, в свою очередь, используется авторизатором в API-шлюзе для защиты конечной точки. Чтобы попытаться бороться с этим, я написал свою собственную реализацию формы регистрации / входа, используя Амазонка-когнито-личность-js но он не позволяет определить, какие области передать токену доступа, а вместо этого предоставляет область действия aws.cognito.signin.user.admin.
Я упустил что-то очевидное? Нужно ли мне писать собственную логику в конечной точке обратного вызова, чтобы определить, должен ли токен доступа пользователя иметь области в полезной нагрузке?