JWT (JSON Web Token) — это открытый стандарт, определенный IETF в RFC 7519 (RFC 7515 описывает форму подписи JWS, RFC 7516 описывает шифрование JWE, RFC 7517 определяет ключи JWK) для безопасной передачи 'заявленной' информации о пользователе между HTTP-запросами, потоками OIDC и вызовами микросервисов. Стандартная строка JWT состоит из трех сегментов, закодированных в Base64URL: Header (алгоритм и тип), Payload (Claims, данные пользователя) и Signature (подпись на основе ключа над первыми двумя). Три сегмента соединены точкой `.`, например `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.
**JWT — это не шифрование.** Это самое распространенное заблуждение. Payload по умолчанию является открытым текстом — любой может декодировать его в Base64URL и прочитать содержимое. JWT обеспечивает **обнаружение подделки**, а не конфиденциальность: сервер переподписывает Header.Payload общим ключом и сравнивает с Signature токена. Если они совпадают, токен не был изменен при передаче. Это метафора 'железнодорожного билета с антиподдельным штампом': инспектору важно, настоящий ли билет, а не читаем ли QR-код.
JWT четко разделяет ответственность между 13 алгоритмами. **Семейство HMAC** (HS256/HS384/HS512) использует симметричный ключ для подписи и проверки, быстрое и простое, подходит для одного сервиса или доверенного кластера; секретный ключ должен быть как минимум длиной дайджеста (например, ≥ 32 байт для HS256). **Семейство RSA** (RS256/RS384/RS512) использует RSASSA-PKCS1-v1_5, наиболее распространенную асимметричную схему — подписанты имеют приватный ключ, проверяющие имеют публичный ключ. **Семейство RSA-PSS** (PS256/PS384/PS512) использует более новый padding RSA-PSS с более сильными гарантиями безопасности, предпочитается AWS SigV4 и современными провайдерами идентификации OIDC. **Семейство ECDSA** (ES256/ES384/ES512) использует эллиптические кривые (P-256/P-384/P-521 соответственно) с более короткими подписями и лучшей производительностью. **EdDSA** (в основном Ed25519) чрезвычайно быстр и детерминирован (одно и то же сообщение + один и тот же ключ = одна и та же подпись каждый раз) и является рекомендуемым алгоритмом в OAuth 2.1 и новых протоколах.
Безопасность — это то, где JWT спотыкается в production. OWASP JWT Cheat Sheet перечисляет как минимум четыре жестких правила: (1) никогда не помещайте пароли, национальные идентификационные документы, номера карт или API-ключи как открытый текст в Payload; (2) сервер должен **никогда не доверять полю alg**, объявленному в Header Токена — должен проверять с жестко закодированным алгоритмом, иначе атакующий, переписывающий заголовок на `alg: none`, обходит все (это источник исторических CVE, таких как CVE-2015-9235); (3) секретные ключи HMAC должны быть случайными и иметь как минимум 32 байта, никогда короткие строки; (4) проверка — это больше, чем просто проверки подписи — вы также должны валидировать `exp` (истечение срока), `nbf` (not-before), `iss` (эмитент) и `aud` (аудитория). Этот инструмент выделяет каждый из этих Claims в UI, чтобы вы могли сразу увидеть, является ли сбой проблемой подписи, проблемой времени или проблемой Claims.
JWT не заменяет сессии. Сессии хранят состояние пользователя на сервере (Redis или база данных); JWT упаковывает состояние в токен. Архитектуры микросервисов, stateless API, мобильные клиенты и конфигурации с большим количеством CORS выигрывают от JWT; традиционные корпоративные системы и потоки, требующие мгновенного отзыва (например, 'выгнать этого пользователя сейчас'), по-прежнему лучше обслуживаются сессиями. Этот инструмент охватывает как чистую отладку JWT, так и шаги парсинга Токена / проверки подписи / редактирования Payload миграции с сессий на JWT.