Как работает токен авторизации
Что проверяют
Отличаете ли аутентификацию от авторизации, понимаете ли разницу между самодостаточным и опаковым токеном, и какие проверки на этом строятся в тестах.
Как отвечать
Общая схема. Клиент отправляет учётные данные, сервер их проверяет и выдаёт токен. Дальше каждый запрос несёт токен в заголовке Authorization: Bearer <token>, сервер валидирует его и решает, пускать ли к ресурсу. Пароль больше не передаётся, состояние сессии на сервере может отсутствовать вовсе.
Два вида токенов:
- Опаковый, случайная строка без содержимого. Всё состояние на сервере, отзыв мгновенный, но каждый запрос требует обращения к хранилищу или к endpoint интроспекции.
- JWT, самодостаточный. Три части через точку в base64url:
header.payload.signature. Сервер проверяет подпись своим ключом и не ходит в базу, что дешевле и масштабируется горизонтально.
Payload закодирован, а не зашифрован. Любой, кто держит токен, читает его содержимое обычным декодером base64. Персональные данные и секреты туда класть нельзя, подпись гарантирует только неизменность, а не тайну.
Валидация это не только срок. Проверяются подпись, exp (истечение), nbf, iss (издатель), aud (получатель) и сам алгоритм. Приём alg: none и подмена RS256 на HS256, где публичный ключ используется как секрет, это классические уязвимости библиотек, которые доверяют заголовку токена.
Отзыв. JWT действует до exp, отозвать его без списка блокировки нельзя. Отсюда пара токенов: короткий access (минуты) и долгий refresh, который хранится строже и меняется при каждом обновлении (rotation). Обнаруженное повторное использование старого refresh это сигнал компрометации.
Хранение на клиенте. localStorage доступен любому скрипту на странице, то есть уязвим к XSS. Cookie с флагами HttpOnly, Secure, SameSite от XSS защищает, но требует защиты от CSRF. Передача всегда по HTTPS, токен не должен попадать в URL и в логи.
Термины, которые путают. OAuth 2.0 это протокол делегирования доступа: приложение получает access_token и действует от имени пользователя. Аутентификацию пользователя даёт надстройка OpenID Connect с отдельным id_token. Использовать access_token как удостоверение личности неверно.
Что проверяет тестировщик:
- запрос без токена возвращает 401, с истёкшим тоже 401;
- валидный токен без нужной роли или scope даёт 403, а не 200 и не 401;
- токен с изменённой подписью или payload отвергается;
- токен пользователя A не даёт доступа к объектам пользователя B (проверка на IDOR);
- после logout и после ротации refresh старые токены не работают;
- токен не логируется и не уходит в query-параметрах.
Где спотыкаются
Говорят, что JWT «зашифрован», и что достаточно проверить срок действия. Подпись, издатель, аудитория и алгоритм проверяются наравне с exp, иначе токен подделывается, а истечение при этом остаётся идеально валидным.