Декодер JWT

Що насправді робить декодувальник JWT

JSON Web Token (JWT) виглядає як довгий, непрозорий рядок випадкових символів, але він не зашифрований і не є таємним шифром. Це компактний, безпечний для URL контейнер, що переносить структуровані дані між двома сторонами. Вставте токен у декодувальник вище — і він розбере цей рядок і покаже вам реальний JSON всередині — метадані, заявки, для кого призначений токен і коли він закінчується. Все відбувається прямо у вашому браузері. Токен ніколи не завантажується, не журналюється і нікуди не передається, що є надзвичайно важливим, коли те, що ви перевіряєте, є живим обліковим записом сесії.

Три частини, дві крапки

Кожен коректно сформований JWT — це три рядки в кодуванні Base64url, з'єднані крапками: header.payload.signature. Саме цей одиничний символ крапки вказує парсерам, де закінчується один розділ і починається наступний, і саме тому токен із неправильною кількістю крапок відхиляється ще до того, як щось інше буде прочитано.

Заголовок (header) — це невеликий JSON-об'єкт, що описує сам токен. Він майже завжди містить typ (тип, зазвичай JWT) та alg — алгоритм підпису, наприклад HS256 (HMAC із SHA-256) або RS256 (RSA із SHA-256). Заголовок точно вказує перевіряючому, як був створений підпис.

Корисне навантаження (payload) — це частина, яка цікавить більшість людей. Це ще один JSON-об'єкт, що містить заявки — твердження про користувача і токен. Специфікація поділяє заявки на зареєстровані (стандартні, зарезервовані імена), публічні та приватні (власні імена, які ви вигадуєте для свого застосунку). Декодування корисного навантаження розкриває, хто увійшов у систему, яку роль він має і коли закінчується його сесія.

Підпис (signature) — це криптографічна печатка. Він обчислюється на основі закодованого заголовка та корисного навантаження з використанням алгоритму з заголовка плюс секретного або приватного ключа. Оскільки він охоплює обидва інших розділи, будь-яка зміна в заголовку або корисному навантаженні — навіть один символ — робить його недійсним.

Заявки, які ви зустрінете найчастіше

Зареєстровані заявки — це короткі, трилітерні імена, визначені RFC 7519, щоб різні системи могли взаємодіяти. Кілька з них зустрічаються майже всюди:

• iss — видавець (issuer): хто створив токен (ваш сервер автентифікації або постачальник ідентичності).
• sub — суб'єкт (subject): принципал, про якого йдеться в токені, зазвичай стабільний ідентифікатор користувача.
• aud — аудиторія (audience): одержувач, якому призначений токен. API повинен відхиляти токени, аудиторія яких не відповідає йому самому.
• exp — час закінчення (expiration time): мітка Unix-часу, після якої токен не може бути прийнятий.
• iat — час видачі (issued at): мітка Unix-часу, коли токен був створений.

Ви також можете зустріти nbf (not before — не раніше) і jti (унікальний ідентифікатор токена). Мітки часу — це секунди від 1970 року в UTC, тому декодувальник, що відображає їх як дати у читабельному вигляді, рятує вас від ментальної арифметики при перевірці того, чи не закінчився вже токен.

Декодування — це не верифікація: саме тут люди помиляються

Це розмежування є найважливішим, що слід розуміти про JWT. Декодування означає читання вмісту: воно не потребує ключа і будь-хто, хто тримає токен, може це зробити, оскільки Base64url — це кодування, а не шифрування. Верифікація означає доведення того, що токен є справжнім і незміненим — перерахунок підпису за допомогою правильного секрету або публічного ключа та підтвердження його відповідності.

Цей інструмент декодує. Він показує вам, що токен стверджує, а не те, чи є токен надійним. Токен може бути підробленим, простроченим або повторно використаним, і при цьому декодуватися у цілком чистий JSON. Ніколи не приймайте рішення про авторизацію лише на основі декодованих заявок. У продакшені ви верифікуєте підпис на стороні сервера, перевіряєте exp і підтверджуєте, що iss та aud відповідають очікуваним значенням — використовуючи перевірену бібліотеку, а не власноруч написане порівняння рядків.

Корисне навантаження — не сховище

Оскільки корисне навантаження лише закодоване в Base64url, його може прочитати будь-хто, хто перехопить токен. Ставтеся до всього в ньому як до публічних даних. Не розміщуйте паролі, повні номери банківських карток, секретні ключі або будь-які чутливі персональні дані в заявках JWT — якщо ви можете декодувати їх тут одним кліком, то і будь-хто інший, хто отримає копію, може зробити те ж саме. Підпис захищає від модифікації, але ніколи від читання. Якщо вам справді потрібно приховати вміст корисного навантаження, для цього існують JWE (зашифровані токени) — зовсім інша специфікація.

Конфіденційність та суміжні інструменти

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

Часті запитання