Использовались ли логин и пароль для авторизации на проектах

Авторизация с использованием логина и пароля на проектах: опыт и современные альтернативы

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

Классический сценарий и его тестирование

На традиционных веб-проектах и в монолитных приложениях механизм обычно представлял собой форму с полями username и password, отправляющую POST-запрос. Задачи QA-инженера в таких случаях включали:

• Позитивные и негативные тесты: Проверка входа с корректными данными, обработка ошибок при неверном логине/пароле, пустых полях.
• Валидация полей: Проверка максимальной длины, специальных символов, чувствительности к регистру.
• Безопасность: Тестирование на уязвимости, такие как SQL-инъекция, XSS (Cross-Site Scripting), передача пароля в открытом виде (должен использоваться HTTPS). Простой пример проверки на SQL-инъекцию в поле логина мог выглядеть так:

  ' OR '1'='1' --
  

• Функциональность «Запомнить меня»: Проверка срока жизни cookies сессии.
• Восстановление пароля: Тестирование всего потока — запрос ссылки, её валидность, безопасность.

Современные тенденции и архитектуры

С появлением микросервисной архитектуры, SPA (Single Page Application) и мобильных приложений подход изменился. Логин и пароль часто используются лишь на первом этапе для получения токена доступа (Access Token), например, JWT (JSON Web Token). Система авторизации становится отдельным сервисом (например, Keycloak или кастомным OAuth2-сервером).

Вот как теперь выглядит упрощённый поток, который необходимо тестировать:

1. Клиентское приложение отправляет логин/пароль на auth-service.
2. Сервис авторизации проверяет credentials, генерирует пару токенов: access token (короткоживущий) и refresh token (долгоживущий).
3. Далее все запросы к защищённым ресурсам (user-service, order-service) идут с заголовком Authorization: Bearer <access_token>.

// Пример HTTP-запроса к API с JWT-токеном
fetch('https://api.example.com/v1/orders', {
  method: 'GET',
  headers: {
    'Authorization': 'Bearer eyJhbGciOiJIUzI1NiIsInR5c...', // JWT token
    'Content-Type': 'application/json'
  }
});

Ключевые аспекты тестирования в современных реалиях

Тестирование смещается с проверки простой формы на валидацию работы токенов и интеграции с сервисами:

• Жизненный цикл токенов: Истечение срока действия access token, успешное использование refresh token для его обновления, инвалидация refresh token при повторном использовании.
• Валидация токенов на стороне сервисов: Каждый микросервис должен независимо проверять подпись и claims JWT. Мы тестировали сценарии, когда user-service отвергал токен с истёкшим сроком, даже если order-service его по какой-то ошибке принял.
• Безопасность хранения: В мобильных приложениях и браузерах критически важно, чтобы токены (особенно refresh token) хранились безопасно (например, в Android Keystore, iOS Keychain, или с флагами HttpOnly, Secure для cookies).
• Тестирование OAuth2-потоков: На многих проектах вместо собственной формы используется вход через Google, GitHub и т.д. (OAuth2, OpenID Connect). Здесь мы тестируем корректность redirect URI, обмен authorization code на токен, обработку ошибок от провайдера.

Вывод

Таким образом, да, использование логина и пароля — это фундаментальный опыт. Но сегодня роль QA заключается в глубоком понимании не только элементарной валидации формы, а в тестировании сквозных процессов безопасности и интеграций в распределённых системах, где логин и пароль — лишь отправная точка для получения токенов, которые и становятся главным объектом проверки. Современный инженер должен уметь тестировать всю цепочку: от UI формы до валидации JWT в каждом отдельном микросервисе, используя как ручные методы, так и автоматизацию API-тестов.