Как получить токен Bearer от Auth0 для олицетворения тестового пользователя в интеграционном тесте? - PullRequest
0 голосов
/ 21 января 2020

Context

Я пытаюсь написать несколько интеграционных тестов, которые проверяют правильность моей службы RESTful Web API (. NET Core-based). Чтобы делать запросы, которые mimi c запрашивает браузер пользователя, мне нужно настроить заголовки HttpClient для включения Authorization: Bearer {test-user-1-bearer-token}.

Проблема

Моя проблема в том, что я могу я не могу найти способ программно получить токен (ы) носителя для тестового пользователя (пользователей), которого я создал вручную.

Что я пытался

Согласно моему исследованию Auth0 Архитектурный сценарий ios единственный, который мог бы работать для меня, называется Серверное приложение + API . Этот сценарий основан на получении токена access для тестирующего приложения (а не токена bearer для пользователя, который пытается выдать себя за код). Насколько я понимаю, это лишает меня возможности иметь несколько тестовых учетных записей, которые мне необходимы, чтобы иметь возможность тестировать сложные сценарии многопользовательского взаимодействия ios вокруг моего Web API.

Альтернативный подход

Вместо использования реального готового промежуточного программного обеспечения для аутентификации я мог бы использовать собственное промежуточное программное обеспечение при запуске экземпляра службы для тестирования. Например, переменная окружения может принять решение о том, какое промежуточное ПО AuthN включить. Это пользовательское промежуточное программное обеспечение может полагаться на источник токена, отличный от JWT (например, пользовательский заголовок HTTP), чтобы обойти аутентификацию Auth0. 10

Было бы неплохо иметь возможность протестировать с Auth0, играющим свою роль.

Тьфу

I Подозреваю, что мой вопрос не по теме c, потому что я не предоставляю код. Надеюсь, я хотя бы получу несколько ответов или комментариев, которые дадут мне подсказку.

1 Ответ

0 голосов
/ 22 января 2020

Для интеграционных тестов вы можете проверить, поддерживает ли ваша служба аутентификации поток проверки пароля владельца ресурса или поток учетных данных клиента - было бы проще получить токен доступа.

Если вы все еще собираетесь делать это с неявным потоком - есть похожий вопрос - https://devforum.okta.com/t/unit-testing-and-implicit-flow/1210/3. Вам нужно будет перейти с сервиса аутентификации Okta на ваш.

Ps

Этот сценарий основан на получении токена доступа для тестирующего приложения (не токен-носитель для пользователя с кодом пытается выдать себя за другого)

Токен на предъявителя является токеном доступа. Неважно, кто его несет, тестирует приложение или конечный пользователь.

...