Вопрос: Автоматическое тестирование 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 = имя пользователя, чтобы получить токен доступа для
  • область, содержащая «тестирование»,

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

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


15


источник


Ответы:


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

  1. Другим способом может быть client_credentials предоставить. Ты будешь необходимо заставить сервер авторизации возвратить access_token что напоминает access_token который будет возвращен пользователю в OpenID Подключите поток через браузер, но в зависимости от вашего AS реализация должна быть выполнимой.

  2. Загрузите ваш клиент, используя обычный поток браузера 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 только.


5