JWT Decoder

Вставте будь-який JWT-токен і миттєво побачте його декодовані заголовок і корисне навантаження у вигляді відформатованого JSON.

Наш дешифратор:

• визначає алгоритм підпису
• відображає всі стандартні та власні твердження
• конвертує часові мітки Unix у зручні для читання дати

Кольорове виділення дозволяє легко розрізнити три частини JWT.

Виносьте помилки JWT, перевіряючи час закінчення терміну дії, часові мітки випуску та значення тверджень.

Наш інструмент показує, чи минув термін дії токенів, скільки часу залишилося до його завершення, а також виділяє потенційні проблеми.

Незамінно для:

• розробки API
• налагодження автентифікації
• аудиту безпеки

JSON Web Token (JWT) — це компактний та безпечний для URL спосіб представлення тверджень, що передаються між двома сторонами, визначений стандартом RFC 7519 від IETF.

JWT складається з трьох частин, розділених крапками, кожна з яких закодована у форматі Base64URL згідно з RFC 4648:

• заголовок, який за допомогою JSON (RFC 8259) оголошує алгоритм підпису та тип токена
• корисне навантаження, що містить твердження — дані про об'єкт, наприклад користувача, а також метадані на кшталт терміну дії
• підпис, що об'єднує заголовок і корисне навантаження, роблячи будь-яке втручання виявленим

Ця структура дозволяє сервісам перевіряти особистість без звернення до бази даних, тому JWT часто використовують для безстанної автентифікації та потоків OpenID Connect.

Щоб декодувати JWT, розділіть токен за двома крапками на три сегменти, а потім застосуйте Base64URL-декодування до перших двох.

Перший сегмент дає JSON заголовка, а другий — JSON корисного навантаження, і обидва читаються як звичайний текст згідно з RFC 8259.

Base64URL (RFC 4648, розділ 5) замінює '+' на '-' і '/' на '_' та пропускає заповнення, тому стандартний декодер Base64 може не спрацювати без коригування. Наш інструмент обробляє це автоматично та гарно форматує результат.

Третій сегмент, підпис, не дешифрується в текст, оскільки він є сирим криптографічним значенням.

Як зазначають в MDN Web Docs, декодування — це не перевірка — читання корисного навантаження ніколи не підтверджує справжність токена.

Ні — стандартний підписаний JWT (JWS) закодований, а не зашифрований, тому будь-хто, хто має токен, може прочитати його корисне навантаження.

Кодування Base64URL (RFC 4648) є зворотним і забезпечує нульову конфіденційність; воно лише робить можливим безпечне транспортування двійкових даних. Підпис, описаний у RFC 7515 (JSON Web Signature), захищає цілісність та автентичність, а не таємність.

Якщо вам потрібно приховати вміст, використовуйте замість цього JWE (JSON Web Encryption, RFC 7516).

OWASP та IETF наголошують на цій відмінності: ніколи не розміщуйте паролі, секрети API чи персональні дані в кориснoму навантаженні підписаного JWT, оскільки такий декодер розкриває кожне твердження у звичайному тексті без жодного ключа.

Зареєстровані твердження JWT стандартизовані RFC 7519, щоб різні системи інтерпретували їх однаково.

Основний набір включає:

• 'iss' (видавець)
• 'sub' (суб'єкт, володар токена)
• 'aud' (аудиторія, призначений одержувач)
• 'exp' (час закінчення терміну дії)
• 'nbf' (дійсний з)
• 'iat' (час видачі)
• 'jti' (унікальний ідентифікатор токена)

Значення exp, nbf та iat є значеннями NumericDate — секундами з моменту початку епохи Unix, які наш декодер перетворює на зрозумілі для людини дати. Додатки додають власні (приватні) твердження для ролей, областей дії або ідентифікаторів орендарів.

Згідно зі специфікацією, засоби перевірки повинні відхиляти токен, чий 'exp' минув або чий 'aud' не відповідає очікуваній аудиторії, запобігаючи зловживанням між сервісами.

Алгоритми підпису JWT визначені в RFC 7518 (JSON Web Algorithms) та ідентифікуються за значенням 'alg' у заголовку.

• HMAC-алгоритми (HS256, HS384, HS512) використовують один спільний секрет як для підписання, так і для перевірки, що є простим, але вимагає від кожного перевіряльника володіти цим секретом.
• RSA-алгоритми (RS256, RS384, RS512) та RSASSA-PSS (PS256) використовують приватний ключ для підпису та публічний ключ для перевірки, що ідеально підходить для розподілених систем та OpenID Connect.
• ECDSA-алгоритми (ES256, ES384, ES512) пропонують еквівалентну безпеку з меншими ключами та підписами.

NIST публікує базові стандарти SHA-2 та ECDSA. Наш декодер зчитує поле 'alg', щоб ви могли перевірити, яку схему використовує токен.

JWT широко використовуються для автентифікації без збереження стану (stateless), авторизації та безпечного обміну інформацією в сучасних API.

Після того як користувач входить у систему, сервер видає підписаний JWT, який клієнт повертає в заголовку HTTP Authorization як Bearer-токен, відповідно до RFC 6750. Оскільки підпис є самодоста тнім, бекенд-сервіси можуть перевіряти токен без запитів до сховища сесій, що покращує масштабованість.

JWT також забезпечують роботу ID-токенів OpenID Connect та патернів токенів доступу OAuth 2.0.

Розробники використовують декодери під час відлагодження, щоб перевіряти claims (твердження), підтверджувати значення аудиторії та видавця, а також контролювати термін дії, коли API повертає помилки 401. Як зазначається в документації MDN Web Docs, такий потік на основі токенів лежить в основі багатьох архітектур єдиного входу (SSO) та мікросервісів.

Безпечне використання JWT базується на перевірці алгоритму, перевірці підпису та дотриманні терміну дії.

OWASP застерігає від класичної атаки "alg: none" та атак на плутанину алгоритмів, коли сервер, обманутий тим, що публічний ключ RS256 сприймається як секрет HMAC, може бути скомпрометований; завжди фіксуйте очікуваний алгоритм, а не довіряйте заголовку.

Основні практики:

• Використовуйте короткий час життя 'exp' разом із токенами оновлення (refresh tokens), а також перевіряйте 'iss' та 'aud' для кожного запиту.
• Ніколи не зберігайте конфіденційну інформацію в корисних даних (payload), оскільки він лише закодований у Base64.
• Передавайте токени виключно через HTTPS і зважайте на стратегії відкликання, оскільки стандартні JWT неможливо індивідуально заблокувати до закінчення їхнього терміну дії.

Дотримання цих рекомендацій IETF та OWASP допомагає усунути найпоширеніші вразливості JWT.

Найпоширеніші помилки під час роботи з JWT включають:

• Плутанину між декодуванням та перевіркою: читання корисної інформації (payload) за допомогою декодера нічого не доводить стосовно автентичності, адже будь-хто може створити непідписаний або підроблений токен.
• Сліпу довіру до значення 'alg' у заголовку, що відкриває шлях до атак на плутанину алгоритмів, на які вказує OWASP.
• Неправильне читання терміну дії через порівняння секунд епохи 'exp' з мілісекундами, через що дійсні токени здаються простроченими.
• Використання стандартного декодера Base64 замість Base64URL (RFC 4648), що може призвести до пошкодження результату через відмінність алфавіту та відсутність доповнення (padding).
• Розміщення чутливих даних у корисних даних (payload), що призводить до їх витоку, оскільки токен закодований, а не зашифрований.

Перевірка підписів на стороні сервера за допомогою очікуваного ключа та алгоритму допомагає уникнути цих пасток.

Цей JWT-декодер обробляє токени повністю на стороні клієнта, тому ваш токен ніколи не залишає ваш пристрій і не потрапляє на жоден сервер.

Оскільки підписаний JWT закодований лише у форматі Base64URL (RFC 4648), для декодування не потрібні мережеві запити — заголовок і корисні дані просто відновлюються з їхнього закодованого вигляду за допомогою JavaScript у вашому браузері.

Збереження локальності операцій має критичне значення для безпеки: токени часто містять дані активних сесій, і вставка їх у сторонній серверний інструмент може призвести до їх витоку в логах або під час передачі. OWASP рекомендує мінімізувати шляхи переміщення чутливих облікових даних.

Браузерний декодер дозволяє розробникам безпечно перевіряти виробничі токени під час налагодження, дотримуючись принципів мінімальної достатності повноважень, без передачі даних авторизації третім особам.