Наш сценарий состоит в том, что у нас есть API, который в настоящее время защищен только ключом подписки в APIM.
Мы планируем изменить это, чтобы также защитить его с помощью OAuth 2, следуя этому руководству от Microsoft, затем мы будем использовать политики проверки JWT в APIM, чтобы гарантировать, что пользователь, запрашивающий доступ, является участником из соответствующих групп для доступа к данным конечным точкам и т. д. c.
Однако в рамках нашего процесса выпуска нам нужно запустить несколько автоматических тестов, которые вызывают API и проверяют, возвращаются ли определенные данные.
Поскольку эти тесты выполняются как часть конвейера автоматического выпуска, мы пытаемся понять, как OAuth будет вписываться в этот процесс - поскольку пользователю необходимо ввести учетные данные для выдачи токена ...
Мы Первоначально считалось, что мы могли бы просто запросить токен вручную один раз, а затем жестко запрограммировать его в тестах, но поскольку токены действительны только в течение короткого времени, это не очень хорошее решение.
Другие вещи, которые мы рассматриваем: :
- Создание «тестового пользователя» в AD и сохранение его учетных данных в тесте p roject, а затем при запуске тестов мы можем запросить токен, используя тип предоставления «Пароль» и передавая имя пользователя и пароль », однако это не выглядит лучшим с точки зрения безопасности, даже если пользователь будет иметь доступ только для очень ограниченного подмножества функций API это все еще не кажется хорошей практикой.
- Запрос токена с использованием секрета клиента, однако недостатком этого является то, что JWT не содержит
groups утверждают, что этот токен не пройдет проверку JWT.
Это должно быть что-то, с чем сталкивались другие? Какова лучшая практика в этом сценарии?