JWT (JSON Web Token) — открытый стандарт (RFC 7519) для передачи данных между участниками в виде подписанного JSON-объекта. Широко используется для авторизации в REST API: после успешной аутентификации сервер выдаёт JWT, клиент сохраняет его и отправляет с каждым последующим запросом в заголовке Authorization: Bearer <token>.
Как работает JWT
JWT состоит из трёх частей, разделённых точками: header.payload.signature. Каждая часть закодирована Base64URL.
- Header — тип токена (JWT) и алгоритм подписи (HS256, RS256)
- Payload — claims:
sub(subject/user_id),exp(expiration),iat(issued at), произвольные данные - Signature — подпись: HMAC-SHA256 от header+payload с секретным ключом (HS256) или RSA-подпись (RS256)
Сервер проверяет подпись без обращения к базе данных — это главное преимущество JWT перед session-based auth. Токен самодостаточен: содержит всё необходимое для верификации.
Пример payload: {"sub": "1234", "role": "admin", "exp": 1716239022}. Важно: payload не зашифрован, только подписан — его может прочитать любой, кто получит токен. Секретные данные в JWT хранить нельзя.
История
JWT стандартизирован IETF в 2015 году. До него для API-авторизации использовались OAuth 1.0 с громоздкими подписями запросов или простые API-ключи без механизма истечения. JWT сделал stateless-авторизацию доступной: не нужна Redis-сессия или БД для проверки аутентичности. Это упростило горизонтальное масштабирование: любой сервер в кластере может проверить JWT независимо.
На что обращать внимание
Срок жизни (exp) токена — ключевой параметр безопасности. Access token обычно живёт 15–60 минут, refresh token — дни или недели. При компрометации короткоживущий access token быстро станет невалидным. JWT нельзя «отозвать» на сервере без дополнительного хранилища (blacklist в Redis) — это обратная сторона stateless-подхода.
Алгоритм подписи имеет значение: HS256 с shared secret уязвим, если секрет слабый или утёк. RS256 с асимметричными ключами лучше для микросервисов: публичный ключ распространяется между сервисами, приватный хранится только на auth-сервере. Для хранения JWT в браузере предпочтительнее httpOnly cookie, а не localStorage — это защищает от XSS-атак. HTTPS обязателен — JWT в открытом канале перехватывается trivially.
JWT в микросервисной архитектуре
JWT особенно ценен в микросервисах. Каждый сервис может самостоятельно верифицировать токен, не обращаясь к центральному auth-серверу. Публичный ключ (RS256) распространяется между сервисами через JWKS endpoint: /.well-known/jwks.json. Сервис получает публичный ключ при старте и кэширует его — проверка подписи занимает микросекунды.
Refresh token rotation — правильный паттерн: access token с коротким TTL (15 мин) + refresh token с длинным (30 дней). При истечении access token клиент использует refresh token для получения нового access token. Refresh token одноразовый: после использования выдаётся новый, старый инвалидируется в Redis. Если refresh token украден — злоумышленник сможет использовать его только один раз до обнаружения.
Хранение JWT в браузере: httpOnly; Secure; SameSite=Strict cookie предпочтительнее localStorage. Cookie с httpOnly недоступен JavaScript — XSS-атака не украдёт токен. При этом CSRF-защита обязательна: SameSite=Strict не пропускает cross-site запросы с токеном.
Библиотеки для работы с JWT: jsonwebtoken (Node.js), PyJWT (Python), lcobucci/jwt (PHP), java-jwt (Java). Инструмент для отладки: jwt.io — позволяет декодировать и проверить токен в браузере. Никогда не доверяйте payload без верификации подписи — это распространённая ошибка.