Декодиране на JSON Web Token (JWT)

Какво е JWT (JSON уеб токен)?

JSON уеб токен, съкратен до JWT (произнася се "джот"), е формат компактен, дефиниран от RFC 7519, позволяващ транспортирането на поредица от искове (искове) между две страни. JWT, или JWT токен, е доминиращият формат днес за предаване на удостоверена самоличност в HTTP API. JWT се появява като ASCII низ съставен от три сегмента, разделени с точки:

header.payload.signature

Всеки сегмент е кодиран в Base64URL, вариант на Base64 без подплата = и който замества + с - и / с _ така че да може да преминава през URL или HTTP заглавка без допълнително екраниране.

Анатомия на JWT

json web token се състои от три много различни части, всяка от които играе специфична роля в механизма за удостоверяване:

1. Заглавка

Заглавката е JSON обект, който описва как е подписан токенът. Съдържа поне:

• alg (алгоритъм): използваният алгоритъм за подпис. Типични стойности: HS256, RS256, ES256, EdDSA.
• typ (тип): типът на токена, почти винаги "JWT".
• kid (идентификатор на ключ): по избор, идентифицира кой ключ трябва да се използва за проверка на подписа. Практично при наличие на въртящ се комплект ключове (JWKS).

2. Полезен товар

Полезният товар съдържа претенциите, т.е. претенциите, които емитентът прави относно потребителя или сесията. RFC 7519 дефинира седем стандартни претенции (регистрирани искове):

• iss (издател): кой е издал токена, например „https://accounts.google.com“.
• sub (тема): кой притежава токена на практика потребителското име.
• aud (аудитория): за кого е предназначен токенът. Избягвайте токен издаден за API A се приема от API B.
• exp (време на изтичане): Unix клеймо за време, след което токенът вече не е валиден.
• nbf (не преди): клеймо за време, пред което не е маркерът все още активен.
• iat (издадено на): клеймо за издаване на токен.
• jti (JWT ID): уникален идентификатор на токена, използван за отмяна и предотвратяване на повторение.

Към тези стандартни искове обикновено се добавят персонализирани искове, специфични за приложението (роли, обхват, tenant_id, имейл, разрешения...).

3. Подпис

Подписът е криптографски кондензат, изчислен върху base64url(header) + "." + base64url(полезен товар) с помощта на ключ. Тя е тази, която доказва че никой не е променил заглавката или полезния товар след излъчването. Най-често срещаните алгоритми:

• HS256 / HS384 / HS512: HMAC-SHA симетричен подпис. Споделен таен ключ между емитента и верификатора. Просто, но неподходящо, когато има повече от един потребител.
• RS256 / RS384 / RS512: асиметричен RSA подпис. Предавателят се подписва с ключа си частен, всеки потребител проверява със съответния публичен ключ. Де факто стандарт за OAuth2 и OpenID Connect.
• ES256 / ES384 / ES512: ECDSA асиметричен подпис. Същите свойства като RS256, но с много по-къси ключове и подписи.
• EdDSA (Ed25519): модерен, бърз и компактен асиметричен подпис.

Още веднъж: подписът защитава целостта, а не поверителността. The полезният товар остава четим от всеки, който притежава токена.

Защо да декодирам JWT?

Операцията декодиране на токен jwt отговаря на няколко конкретни нужди на разработчика или инженер по безопасност:

• Отстраняване на грешка при удостоверяване: вашият API връща 401 или 403, искате да видите какво всъщност е в полезния товар (sub, scope, роли, exp), а не гадаене.
• Проверка на искове: потвърдете, че токенът съдържа искането очаквано (напр. tenant_id или permissions) преди търсене другаде във веригата за оторизация.
• Изтичане на срока на четене: преобразувайте клеймото exp в човешка дата за потвърдите, че токенът е изтекъл или напротив, че трябва да е все още валиден.
• Одит на сигурността: гарантиране, че услуга на трета страна няма да изтече информация чувствителни в полезния товар (имейли, вътрешни идентификатори, лични данни).
• Обучение и разбиране: вижте конкретно какво a jsonwebtoken, идващ от доставчик на OAuth (Google, Auth0, Keycloak, AWS Cognito) за разберете механиката, без да се гмуркате в документите.
• Изследване на публични токени: проверете JWT, намерен в регистрационни файлове, в бисквитка или в прихванат OAuth обмен.

Декодер срещу верификатор: критичното разграничение

Двете операции изглеждат подобни, но нямат нищо общо по отношение на гаранциите за сигурност:

• Декодирането на JWT се състои от разделяне на низа на . и приложете обратен Base64URL към първите два сегмента. Това е лесно четиво, достъпно на всеки триредов скрипт. Без проверка на подпис не е направено.
• Проверката на JWT се състои от преизчисляване на подписа от заглавката, полезен товар и ключ, след което сравнява резултата с присъстващия в токена подпис. това е което гарантира, че токенът не е бил манипулиран.

Практически извод: декодирането не заслужава доверие. Стига подписа не е проверен с правилния ключ, съдържанието на полезния товар може да е напълно фалшиво. За фаза на доверие, използвайте нашия JWT Verifier.

Как да го използвате

1. Вземете JWT за проверка, например от заглавка Упълномощаване: Носител , от бисквитка на сесия, от localStorage от браузъра или от регистрационен файл на приложение.
2. Поставете пълния низ в полето за въвеждане. Трите сегмента трябва да останат разделени с точки.
3. Инструментът веднага показва заглавката, декодирана във форматиран JSON, с алгоритъма и типа.
4. След това полезният товар се декодира и показва. Виждате всички искове там стандартни и персонализирани.
5. Инструментът също така посочва сигнатурната информация (деклариран алгоритъм, дължина), без да го проверявате.
6. За да потвърдите, че токенът не е бил манипулиран, преминете към нашия JWT Verifier с очаквания публичен ключ или тайна.

Цялото декодиране се извършва във вашия браузър в JavaScript: вашият токен никога не се изпраща към нашите сървъри.

JWT и сигурност: капани, които трябва да се избягват

Няколко златни правила за правилно използване на JWT в производството:

• Винаги проверявайте подписа от страната на сървъра преди да предоставите каквито и да е права. Нашият JWT Verifier илюстрира точно тази операция.
• Предпочитайте RS256 или ES256 пред HS256 за публични API. Подписът asymmetric избягва споделянето на тайна между предавателя и всеки потребител.
• Винаги уважавайте твърдението exp. JWT без изтичане или с твърде далечното издишване е бомба със закъснител в случай на изтичане.
• Потвърдете iss и aud от страна на сървъра, за да предотвратите легитимен токен, издаден за друга услуга, се приема по погрешка.
• Отказване на alg: "none" от страната за проверка. Това е класически недостатък което позволява на нападателя да фалшифицира всякакъв полезен товар.
• Поддържайте продължителността на живота кратка (15 минути например) и сдвоявайте с refresh token е по-дълъг, но може да бъде отменен от страната на сървъра.

Пример за декодиран JWT токен

Ето типичен JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiSm9obi IsImlhdCI6MTUxNjIzOTAyMn0.jrU9j8LZcRK2_BZjqXjU7lEpJbkqmXfTQIu9vT45j-I

След декодиране, ето съдържанието му:

// Заглавка
{
  "alg": "HS256",
  "тип": "JWT"
}

// Полезен товар
{
  "под": "123",
  "име": "Джон",
  "iat": 1516239022
}

// Подпис (двоичен, Base64URL кодиран)
HMACSHA256(
  base64url(заглавка) + "." + base64url(полезен товар),
  тайна
)

Къде да намеря JWT за копиране?

На практика JWT за декриптиране (в смисъл на декодиране) най-често идва от един от тези местоположения:

• HTTP Cookie: отворете инструментите за разработка (F12), раздел Приложение или Съхранение, след това Бисквитки. Намерете бисквитка с име access_token, jwt, session или подобни.
• localStorage / sessionStorage: същия панел, Раздел Локално хранилище. Много SPA съхраняват своя токен там под ключ token или auth.
• Упълномощаване заглавка: раздел Мрежа, изберете един API заявка, прочетете заглавката Authorization: Bearer . Копирайте само част след Носител .
• Сървърни регистрационни файлове: JWT понякога се появява в регистрационните файлове на шлюз или обратен прокси (да се избягва при производство, но полезен при отстраняване на грешки).

Често задавани въпроси

Пример за заявка

curl -X POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute \
  -H "Content-Type: application/json" \
  -d '{"token":"..."}'

Входна схема

Крайни точки

• GET https://cdrn.fr/api/v1/tools - изброява всички достъпни инструменти
• GET https://cdrn.fr/api/v1/tools/jwt-decoder - извлича схемата на този инструмент
• POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute - изпълнява този инструмент с JSON payload