Комментарии 27
1 Делаем запрос на ендпоинт authorize
2 Реверсиженирим страницу регистрации и смотрим какие запросы для авторизации делает страница. Скорее всего это будет один или несколько POST запросов. В самом последнем в ответе будет authorization code.
ЗЫ: Вся сложность конечно в эмуляции страницы регистрации. Например, keycloak использует куку и POST запросы с параметром состояния их легко сэмулировать скриптом.
Поэтому если мы хотим напрямую проводить тесты через фронтальный rest нам нужен этот токен. Вопрос — как его взять? И так это сделать красиво и правильно? Вот тут я не знаю.
Подождите, а в чем проблема-то вообще? Эти токены получаются по стандартному протоколу, который в клиенте реализуется без особых размышлений.
PS
Сейчас трудно встретить систему в которая бы не была rest и не использовала OAuth.
Но вообще, конечно, очень легко. Вы что, не видели сервисов за api key?
Если под клиентом понимать js исполняемый в браузере, то, согласен, без проблем. Можете подсказать где в JMeter есть клиент в котором можно реализовать? Тут в качестве клиента используется selenium.
Можете подсказать где в JMeter есть клиент в котором можно реализовать?
А откуда взялось требование про JMeter? Написано "тесты на фронтальный rest". В любом тестовом инструменте, в котором вы можете написать обращение по HTTP, результаты которого использовать потом, вы можете запросить свой токен.
Я, правда, смотрю, вы пишете, вам неподконтролен сервис, который эти токены выдает… ну что же, тогда вы обречены. Но это проблема того, как вы построили тесты.
Надо обеспечить регулярное нагрузочное тестирование фронтовых рест сервисов.
[...]
А мне вот решение кажется кривым. Ну должен же быть способ обойтись без селениума! Напишите если кто знает. Я не смог ничего нагуглить на тему тестирования OpenID&OAuth2 именно с Authorization Code Grant.
Ваша проблема в том, что у вас задача кривая, потому и решения кривые. Если вам нужно нагрузочное тестирование, вам не нужно тестировать authorization code flow (вы же сервисы тестируете, а не авторизацию?). Соответственно, вы делаете так, чтобы его не было — получая токены любым другим способом.
Но это неважно. Вижу вы архитектор. Вот вы как бы организовали решение? Ну или задачу выпрямили? Мне бы вот подсказку как любым другим способом токены получить!
зы. Дык Селениум в нагрузочном тестировании счас не участвует. Он известным мне способом получает токены. Стабильно, дешево и надежно. И любые другие способы я вот и ищу.
Задача вполне прямая. Нагрузить систему целиком со всеми компонентами.
Тогда вы должны нагружать систему авторизации ровно так, как она будет использоваться — то есть через браузер.
Вот вы как бы организовали решение? Ну или задачу выпрямили?
Выкинул бы сервер авторизации из тестирования. Или, по крайней мере, минимизировал его участие, заменив auth code flow на более простой — например, на resource owner credentials, если вам нужен пользователь обязательно.
Так Keycloak умеет оффлайн токены, которые один раз получил и используй.
На самом деле есть куда более простой способ. Поскольку как уже выяснили, вы не тестируете авторизацию, гораздо проще самостоятельно генерить нужный токен. У вас должен быть публичный ключ, зашитый в рест приложении. Сгенерируйте новую пару private/public key и публичный ключ подложите в свое приложение, а приватным подписывайте генерируемые токены.
У вас должен быть публичный ключ, зашитый в рест приложении.
С чего бы вдруг? Речь, вроде об OAuth 2/OIDC, там такое совершенно не обязательно. Все зависит от того, что там за токены, и как их валидируют.
Я имею в виду, что авторизационный токен (в OAuth 2) вообще не обязан быть JWT, это может быть reference token, который проверяется через валидационный эндпойнт. А может быть JWT, но все равно проверяться через валидационный эндпойнт.
Но даже если там JWT, который используется как self-contained, то есть валидируется подпись и клеймы, то публичный ключ в приложение (обычно) не зашиваются, потому что это резко усложняет его отзыв при компроментации. Публичные ключи обычно лежат в общедоступном месте OP, откуда периодически и забираются; логика, по которой определяется доверенный OP, может быть разной. Если автор поста, по его словам, не может подменить авторизационный сервис, то ожидать, что он сможет подменить публикуемые этим сервисом ключи, я бы не стал.
кроме того что «обычно лежат в общедоступном месте»
OpenID Provider Metadata, значение jwks_uri: "REQUIRED. URL of the OP's JSON Web Key Set [JWK] document. This contains the signing key(s) the RP uses to validate signatures from the OP." Что характерно, Google, Microsoft (Azure AD), Okta, OneLogin, IdentityServer и даже, если я не ошибаюсь, используемый автором поста Keycloak — все это поддерживают и выставляют.
Лично я чаще видел другую практику, когда публичный ключ для проверки подписи токена либо лежит где-нибудь в aws secret manager (или аналогичных сервисах), либо шьётся как например переменная окружения.
Непонятно, какой с этого профит. А если авторизационный сервис еще и не ваш, то будет постоянная проблема поддерживать эти настройки актуальными.
А в чем проблема получить токен с помощью постпроцессора JMeter? "Открываем" нужную страницу, ищем на ней токен, записываем в переменную и используем ее там, где необходимо. Может быть я не понял задачу, но я всегда делаю именно так
By the way, overall, we decided to use selenium pretest step to collect all needed tokens.
Because it works very well and could be easily maintenance of juniors.
Как получить OpenID/OAuth2 токен для тестирования front-end rest сервисов?