Декодер JWT

JSON Web Tokens (JWT) — это компактный, URL-безопасный способ представления утверждений между двумя сторонами. Большинство JWT подписаны с использованием JWS (JSON Web Signature), что обеспечивает целостность, но не шифрует содержимое. Этот инструмент декодирует заголовок и полезную нагрузку, показывает утверждения, отображает временные метки в человекочитаемом формате и показывает статус истечения токена.

Спецификации

• RFC 7519 - JSON Web Token (JWT)
• RFC 7515 - JSON Web Signature (JWS)
• RFC 7516 - JSON Web Encryption (JWE)
• RFC 7518 - JSON Web Algorithms (JWA)
• jwt.io - JWT Debugger

Типичные сценарии использования

• Отладка потоков аутентификации OAuth 2.0 и OpenID Connect
• Просмотр токенов доступа и ID-токенов от провайдеров идентификации (Auth0, Okta, Keycloak)
• Проверка соответствия утверждений токена ожидаемым значениям при разработке API
• Проверка истечения токена при устранении ошибок "401 Unauthorized"
• Понимание структуры токена при интеграции со сторонними сервисами
• Аудит токенов для проверки безопасности (алгоритм, утверждения, истечение)

Возможности

• Декодирование заголовка и полезной нагрузки JWT (формат JWS)
• Отображение алгоритма (HS256, RS256, ES256, PS256, EdDSA) и типа токена
• Разбор зарегистрированных утверждений: iss (издатель), sub (субъект), aud (аудитория), exp (истечение), nbf (не ранее), iat (выдан), jti (идентификатор JWT)
• Показ статуса истечения с человекочитаемым обратным отсчётом
• Копирование декодированных секций как форматированного JSON

Примеры

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE5MTYyMzkwMjJ9.4S5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5

Советы

• JWS-токены (наиболее распространённый тип) подписаны, но не зашифрованы. Любой, у кого есть токен, может прочитать полезную нагрузку, декодировав Base64.
• JWE-токены шифруют полезную нагрузку, но встречаются реже. Этот инструмент декодирует JWS-токены.
• Всегда проверяйте подписи на стороне сервера перед доверием утверждениям. Этот инструмент показывает декодированное содержимое, но не проверяет подписи.
• Алгоритм "alg": "none" представляет угрозу безопасности и должен отклоняться серверами.
• Симметричные алгоритмы (HS256) используют общий секрет; асимметричные (RS256, ES256) используют пары открытых/закрытых ключей.
• Утверждение "exp" — это временная метка Unix в секундах. Проверяйте его, чтобы не принимать просроченные токены.

Описание Декодер JWT

JSON Web Tokens (JWT) — доминирующий формат токенов для современной веб-аутентификации и авторизации. JWT — это компактная, URL-безопасная строка, состоящая из трёх сегментов, закодированных в Base64url и разделённых точками: заголовок, указывающий алгоритм подписи, полезная нагрузка, содержащая утверждения о пользователе или сессии, и криптографическая подпись, гарантирующая, что токен не был изменён. Такая структура позволяет любой стороне прочитать содержимое токена простым декодированием Base64, тогда как только стороны с ключом подписи могут создавать или проверять валидные токены.

Большинство JWT используют формат JWS (JSON Web Signature), где полезная нагрузка подписана, но не зашифрована. Поле "alg" заголовка указывает алгоритм: симметричные алгоритмы, такие как HS256, используют общий секрет, известный и издателю, и проверяющему, тогда как асимметричные алгоритмы, такие как RS256 и ES256, используют закрытый ключ для подписи и открытый ключ для проверки. Асимметричные алгоритмы предпочтительны в распределённых системах, поскольку ключ проверки может быть открыто опубликован без компрометации ключа подписи.

Полезная нагрузка содержит зарегистрированные утверждения, определённые RFC 7519: "iss" (издатель), "sub" (субъект), "aud" (аудитория), "exp" (время истечения), "nbf" (не ранее), "iat" (время выдачи) и "jti" (идентификатор JWT). OAuth 2.0 и OpenID Connect добавляют дополнительные утверждения для областей действия, ролей и информации профиля пользователя. Утверждение "exp" критически важно для безопасности — токены без истечения или с чрезмерно длительным сроком действия являются распространённой уязвимостью.

JWT используются в токенах доступа OAuth 2.0, ID-токенах OpenID Connect, аутентификации API и управлении сессиями. Провайдеры идентификации, такие как Auth0, Okta и Keycloak, выдают JWT, которые приложения проверяют без обращения к провайдеру, обеспечивая аутентификацию без состояния. Однако это также означает, что отзыв затруднён — скомпрометированный токен остаётся действительным до истечения срока, поэтому короткие сроки жизни и потоки обновления токенов являются необходимыми практиками безопасности.

Поскольку JWS-токены закодированы в Base64url, а не зашифрованы, любой, кто обладает токеном, может декодировать и прочитать заголовок и полезную нагрузку. Конфиденциальная информация, такая как пароли, номера кредитных карт и секреты, никогда не должна размещаться в полезной нагрузке JWT. JWE (JSON Web Encryption) токены действительно шифруют полезную нагрузку, но они гораздо менее распространены на практике. Различие между кодированием и шифрованием — одна из важнейших вещей для понимания при работе с JWT.

Выбор алгоритма подписи имеет значительные последствия для безопасности. HS256 — симметричный алгоритм, использующий один общий секрет как для подписи, так и для проверки, что упрощает реализацию, но требует, чтобы обе стороны безопасно хранили один и тот же секрет. RS256 и ES256 — асимметричные алгоритмы, использующие закрытый ключ для подписи и открытый для проверки. В распределённых системах асимметричные алгоритмы предпочтительны, поскольку открытый ключ можно свободно распространять — часто через эндпоинт JWKS (JSON Web Key Set) — без компрометации ключа подписи. Параметр "alg": "none" сигнализирует о неподписанном токене без подписи вообще, что означает, что любой может подделать токены с произвольными утверждениями. Известная атака включает изменение заголовка алгоритма на "none" и удаление подписи. Серверы должны всегда проверять алгоритм по белому списку и отклонять неподписанные токены.

Правильная обработка истечения необходима для безопасности JWT. Приложения должны проверять утверждение "exp" при каждом запросе перед доверием токену. Когда токен истекает, токен обновления (хранимый безопасно, часто в httpOnly-куке) может использоваться для получения нового токена доступа без повторного входа пользователя. Короткие сроки жизни токенов доступа — обычно от 5 до 15 минут — ограничивают окно уязвимости при компрометации токена. Реализация упреждающего обновления токена до фактического истечения токена доступа предотвращает прерывания для пользователя в приложении.