Многие из нас хотя бы раз сталкивались с интеграцией сторонних сервисов на проектах. Обычно такую функциональность мы тестируем вручную, авторизуясь через Google-аккаунт и подобные сервисы.
Когда же дело доходит до тестирования API, часто возникает вопрос: как можно автоматизировать этот процесс? Какой способ генерации токенов даст больше преимуществ в случае одной интеграции… А в случае десятка?
В этой статье я хочу описать основные способы авторизации OAuth 2.0Протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе. Он избавляет от необходимости доверять приложению логин и пароль. во время реализации API-тестов, а также их преимущества и недостатки.
Авторизации через сервис-аккаунт часто бывает достаточно для получения доступа к ресурсам во время автотестов. Но бывают ситуации, когда нам нужно знать, кто заходит в систему, какие права есть у пользователя и так далее. В таких случаях нам нужно использовать веб-сервер-авторизацию, которая требует действий пользователя. Об этом и поговорим.
OAuth 2.0: сценарий для веб-серверных приложений
В целом, OAuth 2.0 Authorization code flow включает в себя:
- Процесс авторизации начинается, когда ваше приложение перенаправляет браузер на URL страницы авторизации стороннего сервиса. URL-адрес включает параметры запроса, которые указывают тип запрашиваемого доступа, id клиента, функциональность, права на которую запрашиваются (scope), адрес, на который будет перенаправлен пользователь после проверки (redirect url).
- Сторонний сервис API обрабатывает аутентификацию пользователя, выбор сессии и согласие пользователя (сonsent dialog).
- Результат — код авторизации, который приложение может обменять на access token и refresh token.
Наиболее проблемная для автоматизации часть сценария — второй пункт, поскольку реализация может варьироваться в зависимости от сервиса, и мы не можем контролировать, каким способом сервис обрабатывает аутентификацию пользователя. Кроме того, здесь требуются действия пользователя.
Способы автоматизации сценария авторизации
Отталкиваясь от требований проекта, мы можем реализовать сценарий авторизации OAuth2.0 двумя способами:
- только через HTTP-запросы;
- через сочетание HTTP-запросов и взаимодействия с браузером.
Подход №1: использование HTTP-запросов
Основная идея этого подхода — использовании только HTTP-протокола для авторизации пользователя, включая отправку сервису учетных данных пользователя.
Перед реализацией нам необходимо собрать следующую информацию:
- Authorization URL (обычно упоминается в документации стороннего сервиса);
- Token URL (обычно упоминается в документации стороннего сервиса);
- Redirect URL (обычно упоминается в документации стороннего сервиса);
- Scopes – ресурсы, к которым мы хотим получить доступ (список предоставляемых ресурсов обычно упоминается в документации стороннего сервиса);
- Client Id;
- Client Secret;
- логин;
- пароль.
Получив все необходимые данные, мы можем перейти к реализации сценария авторизации.
Ниже я привожу пример модуля авторизации для Box Service, реализованного на PowerShell.
Самая трудоемкая часть этого подхода связана с общей формой входа и подтверждения пользователя, поскольку нам нужно выяснить, как передать учетные данные пользователя в запрос и какие заголовки нужны, чтобы запрос работал.
Преимущества | Недостатки |
1. Стабильность. Скрипт работает стабильно по сравнению с подходом, когда мы взаимодействуем с браузером.
2. Быстрый запуск. Поскольку мы не настраиваем драйвер, это экономит время при запуске скрипта.
3. Не требует дополнительных настроек в CI. |
1. Довольно долгое время на реализацию из-за особенностей реализации OAuth 2.0 конкретного стороннего сервиса.
2. Требует конфиденциальной информации, например client_secret. |
Подход №2: HTTP-запрос и взаимодействие с браузером
Основная идея — выполнить самую трудоемкую часть подхода №1 с помощью веб-драйвера.
Данные, которые нужно собрать:
- Authorization URL (обычно упоминается в документации стороннего сервиса);
- Token URL (обычно упоминается в документации стороннего сервиса);
- Redirect URL (обычно упоминается в документации стороннего сервиса);
- Scopes — ресурсы, к которым мы хотим получить доступ (список предоставляемых ресурсов обычно упоминается в документации стороннего сервиса);
- Client Id;
- логин;
- пароль.
Ниже можно найти UML-диаграммы этого подхода:
Здесь переиспользуемые классы отмечены зеленым. Единственное, что нужно добавить для подключения нового стороннего сервиса — это объект страницы AuthForm для соответствующего сервиса (оранжевый класс на изображении).
Преимущества | Недостатки |
1. Быстрая реализация. Самая трудоемкая часть реализуется с помощью веб-драйвера, что ускоряет процесс реализации.
2. Не требует конфиденциальной информации, такой как client_secret.
3. Флоу можно использовать повторно. |
1. Исполнение может занять больше времени из-за необходимости настройки и старта веб-драйвера.
2. Требует дополнительной контейнеризации в CI.
3. Имеется риск нестабильности процесса авторизации из-за использования веб-драйвера. |
Вывод
Оба подхода имеют свои недостатки и преимущества и могут быть реализованы в рамках автоматизации тестов. Но давайте обозначим условия, при которых мы можем извлечь из каждого подхода максимум преимуществ.
Если ваш проект интегрируется с одним сторонним сервисом, можно использовать только HTTP-запросы для авторизации. С подходом №1 вы потратите больше времени на реализацию, но это произойдет только один раз.
Если же есть две или больше интеграций со сторонними сервисами, лучшим вариантом будет подход №2, так как он экономит много времени во время реализации механизма авторизации.
Если у вас нет конфиденциальной или другой специфической информации, необходимой для авторизации через HTTP-запрос, также лучше использовать подход №2, поскольку все атрибуты, требующиеся для отправки пользовательских учетных данных на сервер, формируются в браузере автоматически в процессе авторизации через UI.
Читайте также: Фичи Postman, которые облегчат жизнь тестировщика: пошаговая инструкция с видео
Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: