Как работает авторизация между клиентом и сервером и как клиент использует токены

Что проверяют

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

Как отвечать

Сначала термины: аутентификация отвечает на вопрос «кто вы», авторизация на вопрос «что вам можно». Провал первой даёт 401 Unauthorized, второй 403 Forbidden.

Дальше типовая схема:

• вход: клиент отправляет логин и пароль или проходит OAuth 2.0 / OpenID Connect через Authorization Code с PKCE, сервер выдаёт access-токен и refresh-токен;
• access-токен: живёт минуты. Часто это JWT из трёх частей в base64url: заголовок, payload и подпись. Payload не зашифрован, его прочитает любой;
• использование: клиент кладёт токен в заголовок Authorization: Bearer <token>, сервер проверяет подпись, exp, aud и права на конкретный ресурс;
• обновление: когда access истёк, клиент меняет refresh на новую пару. Хорошая практика это ротация, старый refresh после использования перестаёт работать;
• хранение: в браузере безопаснее cookie с HttpOnly, Secure и SameSite плюс защита от CSRF, чем localStorage, откуда токен достанет любой XSS.

Затем покажите свой чек-лист: запрос без токена, с истёкшим, с подделанной подписью, с токеном другого пользователя к чужому ресурсу, повторный refresh после выхода, несколько параллельных запросов с истёкшим токеном. Инструменты: Network в DevTools, Postman с pre-request скриптом для получения токена, Burp Suite или Charles для подмены запросов.

Где спотыкаются

Путают 401 и 403 и не могут сказать, какой код ожидают в каждом случае. Для тестировщика это прямой источник неверно заведённых багов.

Считают JWT зашифрованным. Токен декодируется за секунду, поэтому стоит проверить, что в payload нет паспортных данных, телефонов и прочего лишнего. Боевые токены при этом в онлайн-декодеры не вставляют.

Проверяют только сценарий «зашёл и увидел свой профиль». Самая частая дыра в API другая: подставил в URL чужой id и получил чужие данные. В OWASP API Security Top 10 это первый пункт, Broken Object Level Authorization.