Автоматическое тестирование API API OAuth2/OpenID Connect

Я изучаю новый проект, который мы планируем сначала выполнить API, чтобы затем мы могли реализовывать веб-приложения и собственные приложения, а также допускать стороннюю интеграцию. До сих пор все стандартно.

Мы также хотим иметь полный набор автоматических тестов для API, чтобы гарантировать, что он работает без регрессий, и обеспечить его соответствие требованиям. Опять же, довольно стандартный, но поскольку мы тестируем API, мы будем использовать HTTP-клиент в коде, а не веб-браузер.

Мы смотрели на oauth2/OpenID Connect для упрощения аутентификации и авторизации для API - в основном, чтобы клиенты могли аутентифицироваться, получить токен доступа, а затем использовать его для доступа ко всем ресурсам API.

То, что я пытаюсь выработать, - это хороший способ заставить автоматические тесты работать с частью oauth2, чтобы иметь возможность фактически называть API. Первая мысль заключалась в том, чтобы использовать типы "client_credentials" или "password", которые кажутся похожими на то, что они будут работать для того, что мы хотим, но они вообще не охватываются спецификацией OpenID Connect и, конечно, "пароль" "по крайней мере, это вообще не считается хорошей идеей.

Является ли это лучшим способом для достижения этой цели или существуют другие лучшие практики для такого рода ситуаций, которые могут использоваться с другими потоками, но без веб-браузера?

Изменить: после (много) больше чтения у меня новый план. Выполнение тестов полностью отключено, используя отдельное развертывание против отдельной базы данных и данные о посеве непосредственно в базе данных до запуска тестов, а затем используя стандартные потоки OpenID Connect, но с помощью:

Клиент, который помечен в базе данных для целей тестирования. Это важный бит, и это возможно только в том случае, если клиент может быть зарегистрирован непосредственно в базе данных без прохождения бизнес-логики.
строка = нет
login_hint = имя пользователя, чтобы получить токен доступа для
область, содержащая "тестирование"

Затем система может обнаружить эту комбинацию фактов и автоматически аутентифицировать предоставленное имя пользователя без необходимости проходить через браузер.

Это кажется разумным? Или есть лучший способ?

Ответ 1

Поскольку вы хотите проверить API, не имеет значения, как вы получили access_token, через браузер или каким-либо другим способом. Таким образом, существуют (по крайней мере) два решения:

Другим способом может быть грант client_credentials. Ты будешь необходимо вернуть серверу авторизации access_token, который напоминает access_token, который будет возвращен пользователю в OpenID Подключите поток через браузер, но в зависимости от вашего AS реализация должна быть выполнимой.
Загрузите свой клиент, используя обычный поток браузера OpenID Connect для создания refresh_token рядом с access_token и сохраните оба токена вместе с вашим тестовым клиентом вместе с client_id и client_secret во время настройки. Затем ваш тестовый клиент может получить доступ к API до истечения срока действия access token, а затем получить новый access_token через тип гранта refresh_token (используя client_id и client_secret).

OpenID Connect сам, аутентификация пользователя и id_token не имеют отношения к вашим API-интерфейсам, которые должны заботиться только о access_token.