Что такое JWT-токен

JWT это формат токена, который передает набор claims в компактной строке. Обычно строка выглядит как три части, разделенные точками:

header.payload.signature

header описывает тип токена и алгоритм защиты. payload содержит claims, например sub, role, exp, iss или aud. signature нужна, чтобы получатель мог проверить, что первые две части не изменили.

Главное для интервью такое: JWT не делает данные секретными сам по себе. Если это подписанный токен JWS, payload можно декодировать. Поэтому подпись отвечает за целостность, а не за скрытие данных.

Хороший ответ может звучать так:

JWT это подписанный токен с JSON-claims. Он часто используется как access token: клиент отправляет его с запросом, сервер проверяет подпись, срок действия и права, а затем принимает решение о доступе. На клиенте payload можно декодировать для удобства интерфейса, но нельзя считать это полноценной проверкой безопасности.

Такой ответ показывает три важные вещи. Вы знаете структуру, не путаете подпись с шифрованием и понимаете границу ответственности фронтенда.

Частый вариант для API выглядит так:

GET /api/profile HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Сервер не должен просто декодировать payload и верить ему. Он проверяет подпись, срок действия exp, ожидаемый issuer, audience и права пользователя. Если проверка не прошла, фронтенд должен обработать 401 или 403, а не продолжать считать пользователя авторизованным.

На клиенте декодирование полезно для UX, например показать имя или скрыть кнопку до ответа сервера. Но это не защита. Пользователь контролирует браузер и может изменить клиентский код. Если UI показывает доступ по старому токену, запрос все равно может вернуться с 401 или 403. Поэтому состояние авторизации нужно синхронизировать с ответами API.

Самая частая практическая ловушка связана с хранением токена. Если положить access token в localStorage, с ним удобно работать из JavaScript, но при XSS вредоносный скрипт сможет его прочитать. Если хранить токен в HttpOnly cookie, JavaScript не сможет его украсть напрямую, но cookie может автоматически отправляться с запросами, поэтому нужен контроль CSRF.

Поэтому сильная позиция не звучит как всегда использовать localStorage или всегда использовать cookie. Лучше сказать, что выбор зависит от модели угроз, требований продукта и серверной схемы. Но в любом случае нужны HTTPS, короткий срок жизни access token, защита от XSS и понятная обработка истечения токена. Для SPA также важен один общий refresh flow, чтобы несколько параллельных запросов не запустили несколько обновлений токена и не перетерли состояние друг друга.

Плохой пример, так делать не стоит:

const token = localStorage.getItem("accessToken");
const payload = JSON.parse(atob(token!.split(".")[1]));

if (payload.role === "admin") {
  showAdminPanel();
}

Здесь сразу несколько проблем. Код не проверяет подпись, не проверяет срок жизни, падает на пустом или некорректном токене и смешивает показ UI с реальным доступом. Пользователь может увидеть админский экран на мгновение, получить ошибку на действии или попасть в зависшее состояние, если API вернет 403. Даже если кнопку скрыли или показали правильно, сервер все равно должен проверить права на каждом защищенном запросе.

Более безопасная мысль для фронтенда такая: декодирование можно использовать как оптимизацию интерфейса, но запросы должны проходить через API, где проверяются подпись и claims. Парсинг токена должен быть защищен от ошибок, а UI должен иметь состояния loading, unauthorized и forbidden. Ошибки 401 и 403 нужно явно обрабатывать: обновить токен через единый refresh flow, показать форму входа или убрать недоступное действие без бесконечных повторов запроса.

Если вас спрашивают про logout, важно не обещать магию. Удалить access token в браузере полезно, но это не всегда отзывает уже выданный JWT. Если токен украли до logout, он может работать до exp, если сервер не ведет список отозванных токенов или версию сессии.

Поэтому обычно делают короткий access token и более контролируемый refresh token. Refresh token можно хранить и отзывать на сервере, использовать rotation и обнаруживать повторное применение старого refresh token. Это сложнее, но уменьшает ущерб от утечки.

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

Хорошая финальная фраза:

JWT удобен для stateless access token, но я не стал бы хранить в нем секреты или доверять одной проверке на клиенте. Я бы делал короткий срок жизни, проверял подпись и claims на сервере, аккуратно выбирал место хранения и отдельно продумывал refresh, logout и защиту от XSS/CSRF.