Аутентификация и авторизация - это две разные вещи, которые очень часто путают. Для QA это опасная путаница, потому что из-за неё начинают неверно формулировать баги и пропускать реальные риски доступа.
- →аутентификация отвечает на вопрос "кто ты?"
- →авторизация отвечает на вопрос "что тебе можно?"
Если пользователь ввёл логин и пароль, это ещё не значит, что ему можно открыть любой ресурс или выполнить любое действие. И наоборот, некоторые ресурсы могут быть доступны вообще без входа в систему, но только в ограничённом режиме. Именно поэтому эти два слоя нужно проверять отдельно.
Аутентификация
Аутентификация подтверждает личность пользователя, сервиса или устройства. Система пытается убедиться, что перед ней именно тот субъект, за кого он себя выдаёт.
- →логин и пароль
- →одноразовый код
- →MFA
- →SSO
- →access token или ID token
- →сертификат
- →machine-to-machine credentials
Для QA важно понимать, что аутентификация не заканчивается на успешном логине. Это целая цепочка:
- →пользователь или система предъявляет credential
- →сервер проверяет credential
- →создаётся сессия или выдаётся токен
- →у credential есть срок жизни
- →credential может истечь, быть отозванным, повреждённым или использованным не в том контексте
Из-за этого проверки аутентификации почти всегда шире, чем просто "можно войти" и "нельзя войти".
Авторизация
Авторизация начинается после того, как система поняла, кто перед ней. Теперь нужно решить, что этому субъекту разрешено делать.
- →обычный пользователь может смотреть только свои заказы
- →менеджер может смотреть заказы команды
- →админ может менять статусы пользователей
- →интеграционный сервис может читать данные, но не удалять их
- →анонимный пользователь может открыть публичную страницу, но не личный кабинет
То есть авторизация - это уже не проверка личности, а проверка прав, ролей, политик, ownership и бизнес-ограничений.
Для QA здесь особенно важно помнить: пользователь может быть успешно аутентифицирован, но всё равно не иметь права на конкретное действие. Это не ошибка логина. Это отдельный слой контроля доступа.
Почему их часто путают
Потому что внешне баги выглядят похоже.
- →он не вошёл в систему
- →его токен истёк
- →токен невалидный
- →он вошёл, но у него нет нужной роли
- →он вошёл, роль есть, но он пытается открыть чужой ресурс
- →backend проверяет доступ неправильно
На UI всё это может выглядеть как одно сообщение "нет доступа" или "нужно авторизоваться". Но для QA это разные дефекты, разные причины и разный приоритет.
Что важно QA в аутентификации
- →можно ли войти с корректными данными
- →нельзя ли войти с некорректными данными
- →что происходит при истёкшем токене или сессии
- →как работает logout
- →инвалидируется ли сессия после выхода
- →не сохраняется ли доступ дольше, чем должен
- →как работают remember me, refresh token, MFA, SSO
- →нет ли утечки credential в URL, local storage, логах или network traces
- →что происходит при повторном входе с разных устройств или вкладок
Особенно полезно проверять не только happy path, но и весь жизненный цикл credential. Очень много дефектов сидит не в самом входе, а в продлении, истечении, отзыве и повторном использовании токена или сессии.
Что важно QA в авторизации
- →может ли пользователь видеть только то, что ему положено
- →может ли выполнять только разрешённые действия
- →проверяется ли доступ не только на UI, но и на backend
- →нельзя ли открыть чужой ресурс по прямому ID
- →нет ли лишних прав у роли
- →нет ли ситуации, когда UI скрывает кнопку, но API всё равно выполняет действие
- →одинаково ли применяются правила в web, mobile и API
- →не появляются ли права "по ошибке" после смены роли, статуса или состояния объекта
Одна из самых частых ловушек - проверять авторизацию только через интерфейс. Если кнопка скрыта, это ещё не означает, что доступ защищён. Сильная проверка авторизации почти всегда включает прямой вызов API или хотя бы проверку backend-ответа.
Где ломается чаще всего
- →пользователь может получить чужие данные, если подменит ID в запросе
- →токен старого пользователя продолжает работать после logout
- →смена роли в админке не применяется сразу
- →сервис проверяет роль, но не ownership объекта
- →frontend показывает "запрещено", но backend всё равно исполняет запрос
- →access token валиден дольше, чем ожидается
- →refresh token не отзывается после критичных событий
- →анонимный пользователь видит больше данных, чем должен
С точки зрения безопасности и качества продукта такие дефекты часто важнее, чем обычные UI-баги.
Практический пример
Представь систему заказов.
Пользователь А входит в систему и открывает заказ #1001. Потом в network-запросе или URL меняет ID на #1002.
Если система отвечает данными заказа другого пользователя, проблема не в аутентификации. Пользователь уже успешно вошёл. Проблема в авторизации: backend не проверил, что этот заказ принадлежит именно этому пользователю.
Это один из самых важных типов проверок для QA. Вход может быть реализован идеально, токены могут выдаваться правильно, но если контроль доступа к ресурсам слабый, продукт всё равно остаётся уязвимым.
Что должен вынести QA из этой темы
- →Аутентификация и авторизация - это разные слои.
- →Аутентификация проверяет личность, авторизация проверяет доступ.
- →Успешный логин не означает право на любое действие.
- →UI-ограничения без backend-проверки нельзя считать надёжной защитой.
- →Один из самых важных классов проверок - доступ к чужим данным и чужим действиям.
- →Жизненный цикл токенов, сессий и ролей нужно тестировать так же внимательно, как и сам вход.
Что ещё почитать
- →Внутри базы: HTTP и HTTPS
- →Внутри базы: JWT, OAuth 2.0, API Keys
- →Внешний материал: OWASP Authorization Cheat Sheet