JWT декодер
Поставете JSON Web Token, за да прочетете header и payload, да видите кога изтича и да разберете всеки claim. Токенът ви никога не напуска браузъра.
Работи в браузъраБез регистрацияНищо не се качва
Декодирането не е проверка. Всеки може да прочете header и payload на JWT, защото те са само кодирани в base64url. Инструментът показва какво токенът твърди, но не доказва, че е истински. Винаги проверявайте подписа на сървъра си.
Header
Payload
Обяснение на claims
Проверка на подписа (по избор, HS256/HS384/HS512)
Проверява HMAC подпис с въведена от вас тайна чрез Web Crypto API на браузъра. Тайната никога не напуска тази страница. RSA/ECDSA токените изискват публичния ключ на издателя и тук не се проверяват.
Как да използвате: JWT декодер
- Поставете токена в полето Кодиран токен. Водещото
Bearerот заглавката Authorization се игнорира. - Header и payload се декодират мигновено и се показват като форматиран JSON.
- Прегледайте таблицата Обяснение на claims:
exp,iatиnbfсе преобразуват в дати с „изтича след“ / „изтекъл преди“. - Проверете лентата за състояние за проблеми с изтичането и предупрежденията за рискови настройки като
alg: none. - По избор въведете споделената тайна, за да проверите локално подпис HS256, HS384 или HS512.
Какво има в един JWT?
JSON Web Token (RFC 7519) представлява три base64url низа, свързани с точки: header.payload.signature. Header посочва алгоритъма за подписване (alg) и типа на токена. Payload съдържа claims, например кой е потребителят и кога изтича токенът. Подписът се изчислява върху първите две части с тайна или частен ключ.
Декодирането не е проверка
Header и payload са само кодирани, а не криптирани, така че всеки, който притежава токена, може да ги прочете. Затова никога не слагайте пароли или тайни в payload на JWT. Декодирането показва какво токенът казва. Проверката на подписа, обикновено на вашия API сървър с библиотека като jose или PyJWT, доказва кой го е издал и че не е променян. Сървърът трябва да проверява и exp, nbf, iss и aud и да отхвърля неочаквани алгоритми.
Пищов за регистрираните claims
| Claim | Значение |
|---|---|
iss | Issuer: кой е създал и подписал токена |
sub | Subject: обикновено ID на потребителя |
aud | Audience: за кой API е предназначен токенът |
exp | Време на изтичане в секунди от Unix епохата |
nbf | Невалиден преди този момент |
iat | Време на издаване |
jti | Уникален ID на токена, полезен за списъци с отменени токени |
Дебъгинг на грешки „token expired“
Ако API отхвърля токен, който изглежда пресен, сравнете exp и nbf с часовника на сървъра. Малко разминаване на часовниците между машините е често срещано, затова повечето библиотеки допускат толеранс от 30–60 секунди. Проверете също дали exp е в секунди: стойност в милисекунди е честа грешка и отлага изтичането с хиляди години.
Често задавани въпроси
Безопасно ли е да поставя тук продукционен JWT?
Проверява ли инструментът подписа на JWT?
Защо токенът ми се показва като изтекъл?
exp е в миналото спрямо часовника на компютъра ви. Поискайте нов токен или го опреснете с refresh token. Ако времената изглеждат грешни, проверете за разминаване на часовниците или стойност на exp, записана в милисекунди.Каква е разликата между JWT, JWS и JWE?
Защо alg „none“ е опасен?
alg: none и да приемат само конкретния алгоритъм, който очакват.