Как работает JWT

JWT, JSON Web Token, это строка из трех частей, разделенных точками. Обычно она выглядит так:

header.payload.signature

header описывает тип токена и алгоритм подписи. payload содержит claims, например sub, exp, iat, роль или идентификатор tenant. signature считается по header и payload с секретом или приватным ключом, чтобы сервер мог заметить подделку.

В ответе сразу уточните: JWT не означает шифрование. Если токен не сделан как отдельный encrypted JWT, payload можно прочитать в браузере. Подпись защищает целостность, но не конфиденциальность.

Типичный сценарий такой: пользователь логинится, сервер выдает access token, клиент прикладывает его к защищенным запросам, сервер проверяет подпись и claims. Если проверка прошла, API выполняет действие. Если срок истек или подпись неверная, API возвращает 401 или 403 в зависимости от причины.

Для вашего frontend-кода важно обработать не только успешный запрос, но и истечение токена. Плохой UX получается, когда приложение бесконечно повторяет запросы с истекшим JWT, запускает несколько refresh-запросов одновременно или молча показывает пустой экран.

Сервер не должен просто декодировать payload. Нормальная проверка включает подпись, допустимый алгоритм, срок действия и важные claims. Часто проверяют exp, nbf, iss, aud и права пользователя.

На интервью подчеркните: клиент может прочитать токен, но не принимает окончательное решение о доступе. Сервер остается источником истины, потому что запрос к API можно отправить напрямую, минуя ваш интерфейс.

Если токен передается через заголовок, frontend обычно добавляет его к запросу как Bearer token. Пример ниже показывает только передачу токена. Это не рекомендация хранить его в конкретном месте.

async function loadProfile(accessToken: string) {
  const response = await fetch("/api/profile", {
    headers: {
      Authorization: `Bearer ${accessToken}`,
    },
  });

  if (response.status === 401) {
    // Запустить refresh flow или перевести пользователя на login.
    throw new Error("Session expired");
  }

  if (!response.ok) {
    throw new Error("Cannot load profile");
  }

  return response.json();
}

Не говорите, что такой код сам по себе безопасен. Безопасность зависит от того, где хранится токен, как закрыт XSS, есть ли HTTPS, как работает refresh и что делает сервер при проверке. В реальном UI еще нужны состояние загрузки, понятная ошибка, отмена устаревшего запроса через AbortController или другой механизм и защита от повторного retry после 401.

Частая ошибка в ответе: сразу обещать положить JWT в localStorage и отправлять его в каждом запросе. Это неполный ответ, потому что localStorage читается любым скриптом на странице. При XSS злоумышленник получает готовый bearer token.

HttpOnly cookie тоже не серебряная пуля. Она снижает риск кражи токена через JavaScript, но браузер отправляет cookie автоматически. Поэтому нужно думать про CSRF. Хороший ответ не выбирает вариант наугад, а объясняет модель угроз и компромисс.

Отдельно проговорите refresh flow. Если при каждом 401 делать новый refresh и сразу менять состояние пользователя, можно получить гонку, лишние сетевые вызовы и мигающий UI. Безопаснее централизовать refresh, повторять запрос один раз, отменять устаревшие запросы и очищать приватные данные после окончательной ошибки авторизации.

JWT удобен тем, что сервер может проверить токен без постоянного чтения серверной сессии. Но у этого есть цена: уже выданный JWT трудно мгновенно отозвать, если он самодостаточен и валиден до exp.

На практике часто делают короткоживущий access token и refresh token. Access token живет недолго и используется для API. Refresh token хранится осторожнее и может быть отозван на сервере. Так при краже access token окно риска меньше, а logout можно связать с отзывом refresh token или версии сессии.

Соберите короткий ответ так:

JWT это подписанный токен из header, payload и signature. Payload можно прочитать, поэтому там не должно быть секретов. Сервер проверяет подпись, срок действия и claims при каждом защищенном запросе. На фронтенде я бы отдельно обсудил, где хранить токен, как обрабатывать 401 без бесконечных retry, как работает refresh и что будет при logout.

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