Что такое получение токена в веб-разработке

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

Понимаете ли вы жизненный цикл токена на клиенте: где он берётся, где лежит, когда протухает и что случится при выполнении чужого скрипта на странице. Вопрос звучит просто, но продолжение почти всегда про хранение и обновление, и там видно, делал ли кандидат авторизацию сам.

Как отвечать

Схема: форма отправляет учётные данные на эндпоинт входа, сервер проверяет их и возвращает пару токенов. Короткоживущий токен доступа ходит в заголовке Authorization со схемой Bearer, долгоживущий нужен только для того, чтобы получить новый токен доступа.

Про формат стоит сказать, что тело такого токена не шифруется, а кодируется в base64url и читается кем угодно: персональные данные туда не кладут. Клиент может посмотреть срок жизни и обновиться заранее, но решать по содержимому, что пользователю можно, нельзя: подпись проверяет только сервер.

Хранение: долгоживущий токен в куке с флагами HttpOnly, Secure и SameSite, токен доступа в памяти приложения. Любое хранилище, доступное скрипту, отдаёт токен целиком при первой же уязвимости в зависимости.

Обновление: один общий перехватчик ответа со статусом 401, который просит новый токен и повторяет исходный запрос. Параллельные запросы должны ждать одного обновления, иначе несколько вкладок устроят гонку ротаций и разлогинят пользователя.

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

Называют единственным местом хранения локальное хранилище браузера и не могут объяснить, чем оно опаснее куки. Разница именно в том, что куку с флагом HttpOnly скрипт не прочитает.

Путают аутентификацию и авторизацию: получение токена отвечает на вопрос, кто пользователь, а права проверяются отдельно и всегда на сервере. Прятать кнопку на фронтенде это удобство, а не защита.

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