Авторизация OAuth 2.0: два полезных решения для тестировщиков

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

Когда же дело доходит до тестирования API, часто возникает вопрос: как можно автоматизировать этот процесс? Какой способ генерации токенов даст больше преимуществ в случае одной интеграции… А в случае десятка? 

В этой статье я хочу описать основные способы авторизации OAuth 2.0Протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе. Он избавляет от необходимости доверять приложению логин и пароль. во время реализации API-тестов, а также их преимущества и недостатки.

Авторизации через сервис-аккаунт часто бывает достаточно для получения доступа к ресурсам во время автотестов. Но бывают ситуации, когда нам нужно знать, кто заходит в систему, какие права есть у пользователя и так далее. В таких случаях нам нужно использовать веб-сервер-авторизацию, которая требует действий пользователя. Об этом и поговорим.

OAuth 2.0: сценарий для веб-серверных приложений 

В целом, OAuth 2.0 Authorization code flow включает в себя:

1. Процесс авторизации начинается, когда ваше приложение перенаправляет браузер на URL страницы авторизации стороннего сервиса. URL-адрес включает параметры запроса, которые указывают тип запрашиваемого доступа, id клиента, функциональность, права на которую запрашиваются (scope), адрес, на который будет перенаправлен пользователь после проверки (redirect url).
2. Сторонний сервис API обрабатывает аутентификацию пользователя, выбор сессии и согласие пользователя (сonsent dialog).
3. Результат — код авторизации, который приложение может обменять на access token и refresh token.

Наиболее проблемная для автоматизации часть сценария — второй пункт, поскольку реализация может варьироваться в зависимости от сервиса, и мы не можем контролировать, каким способом сервис обрабатывает аутентификацию пользователя. Кроме того, здесь требуются действия пользователя.

Способы автоматизации сценария авторизации

Отталкиваясь от требований проекта, мы можем реализовать сценарий авторизации OAuth2.0 двумя способами:

• только через HTTP-запросы; 
• через сочетание HTTP-запросов и взаимодействия с браузером.

Подход №1: использование HTTP-запросов 

Основная идея этого подхода — использовании только HTTP-протокола для авторизации пользователя, включая отправку сервису учетных данных пользователя. 

Перед реализацией нам необходимо собрать следующую информацию:

• Authorization URL (обычно упоминается в документации стороннего сервиса);
• Token URL (обычно упоминается в документации стороннего сервиса);
• Redirect URL (обычно упоминается в документации стороннего сервиса);
• Scopes – ресурсы, к которым мы хотим получить доступ (список предоставляемых ресурсов обычно упоминается в документации стороннего сервиса);
• Client Id;
Онлайн-курс Digital Marketing від Mate academy.
На курсі Digital Marketing ви отримаєте усі необхідні навички, щоб отримати нову роботу: навчитесь використовувати цифрові канали для залучення аудиторії, просування брендів, товарів та послуг.
Отримати знижку на курс
• Client Secret;
• логин;
• пароль.

Получив все необходимые данные, мы можем перейти к реализации сценария авторизации.

Ниже я привожу пример модуля авторизации для Box Service, реализованного на PowerShell.

 Самая трудоемкая часть этого подхода связана с общей формой входа и подтверждения пользователя, поскольку нам нужно выяснить, как передать учетные данные пользователя в запрос и какие заголовки нужны, чтобы запрос работал.

Подход №2: HTTP-запрос и взаимодействие с браузером

Основная идея — выполнить самую трудоемкую часть подхода №1 с помощью веб-драйвера.

Данные, которые нужно собрать:

• Authorization URL (обычно упоминается в документации стороннего сервиса);
• Token URL (обычно упоминается в документации стороннего сервиса);
• Redirect URL (обычно упоминается в документации стороннего сервиса);
• Scopes — ресурсы, к которым мы хотим получить доступ (список предоставляемых ресурсов обычно упоминается в документации стороннего сервиса);
• Client Id;
• логин;
• пароль.
Онлайн-курс "Фінансовий аналіз" від Laba.
Опануйте звітність — від збору даних до обробки результатів, та інтерпретуйте дані ключових звітів CF, BS, P&L зрозумілою мовою.
Детальніше про курс

Ниже можно найти UML-диаграммы этого подхода:

UML-диаграмма подхода №2

Здесь переиспользуемые классы отмечены зеленым. Единственное, что нужно добавить для подключения нового стороннего сервиса — это объект страницы AuthForm для соответствующего сервиса (оранжевый класс на изображении). 

Вывод

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

Если ваш проект интегрируется с одним сторонним сервисом, можно использовать только HTTP-запросы для авторизации. С подходом №1 вы потратите больше времени на реализацию, но это произойдет только один раз. 

Если же есть две или больше интеграций со сторонними сервисами, лучшим вариантом будет подход №2, так как он экономит много времени во время реализации механизма авторизации.

Если у вас нет конфиденциальной или другой специфической информации, необходимой для авторизации через HTTP-запрос, также лучше использовать подход №2, поскольку все атрибуты, требующиеся для отправки пользовательских учетных данных на сервер, формируются в браузере автоматически в процессе авторизации через UI.

Читайте также: Фичи Postman, которые облегчат жизнь тестировщика: пошаговая инструкция с видео