Что такое JWT
JSON Web Token (JWT, RFC 7519) — компактная строка с JSON-заголовком и полезной нагрузкой, опционально защищённая подписью или аутентифицированным шифрованием. Обычная подписанная форма — три сегмента Base64URL через точки:
base64url(header) . base64url(payload) . base64url(signature)
В payload обычно входят claims: субъект (sub), аудитория (aud), срок действия (exp) и поля приложения. Поскольку payload подписанного (не зашифрованного) JWT только кодирован, любой, кто получил токен, может прочитать claims. Подпись обнаруживает подмену и с общим секретом или открытым ключом подтверждает, кто выпустил токен.
Просмотрите пример токена инструментом Декодировать JWT—одно декодирование не доказывает, что подпись верна.
Подинструменты этого семейства
- Декодировать JWT — разделяет и декодирует Base64URL заголовок и payload, чтобы читать алгоритмы и claims локально в браузере.
- Подписать JWT HS256 — собирает токен из JSON-payload и общего секрета через HMAC-SHA256.
- Проверить JWT HS256 — пересчитывает подпись HMAC-SHA256 с вашим секретом и сообщает, совпадает ли она.
Типичный путь обучения: подписать одноразовый payload, декодировать и осмотреть claims, затем проверить тем же секретом. Любое изменение символа в payload должно ломать проверку.
HS256 и роль HMAC
HS256 — это HMAC-SHA256 по сегментам header и payload. Издатель и проверяющий делят секрет. Модель подходит first-party API и простым session-токенам. Плохо подходит, когда много недоверенных клиентов должны проверять токены без секрета издателя—там нужны асимметричные алгоритмы (RS256, ES256) с публичным JWKS.
Проверка HS256 сильна лишь настолько, насколько хранение секрета. Встраивание секрета в публичное мобильное приложение или frontend-бандл позволяет кому угодно подделывать токены.
О базовой конструкции MAC см. также хаб HMAC, особенно HMAC SHA-256.
Claims, с которыми нужно быть осторожным
exp / nbf / iat. Окна истечения и not-before предотвращают бесконечное повторное использование. Верификаторы должны отклонять просроченные токены; декодеры, которые только печатают JSON, время за вас не проверяют.
alg. Заголовок объявляет алгоритм. Жёстко задайте ожидаемый алгоритм на верификаторе (например, только HS256). Исторические уязвимости принимали alg: none или переключались с RS256 на HS256, используя открытый ключ как HMAC-секрет.
aud и iss. Проверки аудитории и издателя не дают принимать токены, выпущенные для другого сервиса.
Чувствительные данные в payload. Предпочитайте непрозрачные идентификаторы сырым персональным данным в незашифрованных JWT. Логи, история браузера и заголовки Referer могут утекать токены.
Декодирование против проверки
| Операция | Доказывает читаемость | Доказывает подлинность |
|---|---|---|
| Декодировать | Да (для незашифрованного JWT) | Нет |
| Проверить HS256 | Нужен секрет | Да, если секрет верен и сравнение корректно |
Всегда проверяйте в путях кода, которые авторизуют действия. Декодирование в отладчике — для людей; криптографическая проверка — для машин, принимающих решения о доступе.
Детали Base64URL
JWT использует Base64URL без padding в классической сериализации. Это отличается от стандартного Base64 (+// против -/_). Смешение алфавитов при ручной сборке токенов — частая причина ошибок неверной подписи. Предпочитайте API библиотек для кодирования, а не ручную конкатенацию строк в продакшене.
Типичные сбои
- Рассинхрон часов: только что выпущенный токен кажется «ещё недействительным» или уже просроченным—допускайте небольшой запас, если платформа это документирует.
- UTF-8 и канонизация JSON: повторная подпись после pretty-print меняет байты и ломает подписи.
- Разный секрет в окружениях (staging против production).
- Считать успех декодирования успехом входа.
- Кладка паролей или данных карт в claims JWT.
Ограничения и среда
Эти инструменты сосредоточены на изучении и отладке HS256. Они не реализуют полный стек JOSE (шифрование JWE, каждый алгоритм JWA или федерацию JWKS). Клиентская обработка держит примеры токенов на устройстве; всё же не вставляйте продакшен session-токены на общие машины.
Итог
JWT упаковывают claims в компактную подписанную строку. Этот хаб позволяет декодировать заголовки и payload, подписывать HS256 и проверять подписи HMAC-SHA256. Читайте claims осторожно, проверяйте до доверия, защищайте общие секреты и выбирайте асимметричные алгоритмы, когда верификаторы не должны делить ключ издателя.