JWT (JSON Web Token) — это компактный формат токена, который удобно гонять между сервисами и клиентами. Внутри него лежат утверждения о пользователе или системе, а сам токен можно проверять без обращения к базе. Поэтому JWT так часто используют для аутентификации, авторизации и обмена служебной информацией в распределённых системах.
Структура у токена всегда одна и та же, из трёх кусочков:
- Header — тип токена и алгоритм подписи (например, HS256 или RS256);
- Payload — «начинка»: набор claims — id пользователя, роли, срок действия и любые другие атрибуты;
- Signature — результат подписи header+payload секретным ключом или связкой приватный/публичный ключ.
Все части кодируются и склеиваются через точки в одну строку вида:header.payload.signature
Как в целом работает JWT #
- Пользователь логинится (форма, OAuth, что угодно).
- Сервер создаёт JWT, подписывает его и отдаёт клиенту.
- Клиент где-то хранит токен:
localStorage,sessionStorageилиhttpOnly-cookie — как договоритесь. - При следующих запросах клиент добавляет заголовок
Authorization: Bearer <token>. - Сервер проверяет подпись и срок действия, вытаскивает данные из payload и на этом принимает решение — без отдельного запроса в БД.
Если используется асимметричная подпись вроде RS256, то выпуск токена привязан к приватному ключу, а проверять его может кто угодно, у кого есть публичный. Это очень удобно, когда у вас десяток микросервисов, а центр аутентификации один.
Где JWT реально применяют #
- В REST API, когда не хочется тянуть за собой серверные сессии и хранить их состояние;
- В SPA-приложениях, где логика и состояние живут в браузере, и каждый лишний запрос к серверу — это минус к отзывчивости;
- В микросервисных системах — чтобы сервисы могли доверять токену без центрального хранилища сессий;
- В SSO-сценариях, где JWT выступает носителем информации об идентичности пользователя.
Плюсы JWT #
- Самодостаточность — всё, что нужно, лежит в самом токене, сервер не обязан хранить состояние;
- Универсальность — токен, выпущенный одним сервисом, может спокойно проверяться другим (если они разделяют ключи);
- Производительность — проверка подписи и полей дешевле, чем постоянные запросы к БД за сессией;
- Поддержка — современные фреймворки и библиотеки уже давно умеют работать с JWT из коробки;
- TTL по стандарту — поля
exp,nbf,iatпозволяют задать срок жизни и контролировать валидность без доп. таблиц.
Как это выглядит на практике #
Пользователь успешно залогинился — сервер формирует JWT с id пользователя, списком ролей и временем истечения, подписывает и отдаёт. Браузер сохраняет токен и добавляет его ко всем последующим запросам. Сервер на каждом запросе просто проверяет подпись и дату истечения: если всё нормально — считает пользователя аутентифицированным, без повторных логинов.
JWT описан в RFC 7519 и уже стал стандартным инструментом авторизации для веб-приложений, API и микросервисов. При условии, что грамотно выбраны алгоритмы и ключи не лежат в открытом доступе, он даёт удобный и достаточно надёжный способ передавать удостоверяющую информацию без перегрузки backend'а.
