Какие бывают схемы аутентификации с токенами и без токенов
Что проверяют
Понимаете ли вы, как устроен вход в тестируемую систему, настолько, чтобы проверить его не только на позитивном сценарии. Следом почти всегда просят назвать проверки для JWT или объяснить разницу между кодами 401 и 403.
Как отвечать
Сначала коротко перечислите схемы:
- без токенов: Basic (логин и пароль в Base64 в заголовке
Authorization), почти забытый Digest, сессия после входа через форму (сервер хранит сессию, браузер хранит cookie с её идентификатором), API-ключ в заголовке, клиентский сертификат (mTLS), Kerberos и NTLM в корпоративной сети; - с токенами: JWT (подписанный токен с claims и сроком действия), непрозрачный токен, который сервер проверяет у себя, OAuth 2.0 с OpenID Connect поверх него, SAML в корпоративном SSO.
Дальше покажите, что вы с этим делаете как тестировщик. В Postman это вкладка Authorization и pre-request скрипт, который получает токен, в REST Assured auth().preemptive().basic(...) или auth().oauth2(token). Типовые проверки:
- без учётных данных и с чужими: ожидается 401, с валидным токеном без нужных прав 403;
- истёкший токен и токен после logout: доступ должен закрываться, а при ротации использованный refresh-токен повторно не работает;
- подделанный JWT: изменённый payload со старой подписью,
alg: none, подпись чужим ключом. Сервер обязан отклонить; - cookie: флаги
HttpOnly,Secure,SameSite, смена идентификатора сессии после входа, защита от CSRF; - перебор: блокировка или ограничение частоты после нескольких неудачных попыток.
Где спотыкаются
Путают 401 и 403. 401 означает «не знаю, кто вы», 403 означает «знаю, но нельзя».
Считают, что JWT зашифрован. Он подписан, а payload читается любым декодером, поэтому проверка, что в токене нет паролей и лишних персональных данных, тоже нужна.
Хранят рабочие токены и пароли прямо в коллекциях и в репозитории автотестов, а продовые JWT вставляют в онлайн-декодеры. Секреты должны приходить из переменных окружения или хранилища секретов CI.