Skip to main content
CheckTown
Валідатори

Валідатор JWT: Перевірте структуру та заявки JSON Web Token

Опубліковано 6 хв читання
У цій статті

Що таке JWT?

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

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

Структура JWT

JWT складається з трьох частин, закодованих у Base64URL, розділених крапками: header.payload.signature.

  • Заголовок — JSON-об'єкт, що вказує тип токена (JWT) та алгоритм підпису (наприклад, HS256, RS256, ES256)
  • Корисне навантаження — JSON-об'єкт, що містить заявки: зареєстровані заявки (iss, sub, exp, iat), публічні заявки та приватні заявки
  • Підпис — створюється шляхом підписання закодованого заголовка та корисного навантаження секретним ключем (HMAC) або приватним ключем (RSA/ECDSA)

Спробуйте безкоштовно — реєстрація не потрібна

Перевірити JWT →

Як працює перевірка JWT

Валідація JWT включає структурні перевірки, верифікацію підпису та валідацію заявок.

  • Перевірка структури — токен повинен містити рівно три сегменти в Base64URL-кодуванні, розділені двома крапками
  • Валідація заголовка — заголовок повинен містити валідні поля typ та alg. Алгоритм повинен відповідати очікуваному сервером
  • Верифікація підпису — підпис перераховується за допомогою заголовка, корисного навантаження та ключа підпису. Якщо перерахований підпис збігається, токен не був підроблений
  • Валідація заявок — заявки exp (термін дії), nbf (не раніше) та iss (видавець) перевіряються відносно поточного часу та очікуваних значень

Поширені варіанти використання

JWT забезпечують автентифікацію та авторизацію в усьому стеку сучасного вебу.

  • Автентифікація API — клієнти включають JWT у заголовки Authorization (схема Bearer) для автентифікації API-запитів без сесій
  • Єдиний вхід (SSO) — постачальники ідентичності видають JWT, які приймають кілька застосунків, забезпечуючи безперебійну міжзастосункову автентифікацію
  • Токени доступу OAuth 2.0 — багато реалізацій OAuth використовують JWT як токени доступу, кодуючи дозволи та права доступу безпосередньо в токені
  • Комунікація мікросервісів — сервіси передають JWT для поширення контексту користувача та рішень щодо авторизації через межі сервісів

Найкращі практики безпеки JWT

JWT є потужними, але вимагають обережного поводження, щоб уникнути поширених вразливостей безпеки.

  • Завжди перевіряйте алгоритм — ніколи не дозволяйте полю alg з токена диктувати, який алгоритм використовує ваш сервер. Це запобігає атаці з алгоритмом none
  • Встановлюйте короткий термін дії — JWT не можна відкликати після видачі. Зберігайте час exp коротким (15 хвилин для токенів доступу) та використовуйте токени оновлення для довгострокових сесій
  • Використовуйте асиметричні алгоритми для розподілених систем — RS256 або ES256 дозволяють сервісам перевіряти токени без спільного використання секрету підпису
  • Ніколи не зберігайте чутливі дані в корисному навантаженні — JWT закодовані, не зашифровані. Будь-хто може декодувати корисне навантаження. Зберігайте секрети у своїй базі даних, не в токені

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

Чи можна декодувати JWT без секретного ключа?

Так. Корисні навантаження JWT закодовані у Base64URL, не зашифровані. Будь-хто може декодувати та прочитати заголовок та корисне навантаження. Секретний ключ потрібен лише для верифікації підпису — для підтвердження того, що токен не був змінений.

У чому різниця між JWS та JWE?

JWS (JSON Web Signature) — це те, що більшість людей розуміє під JWT — підписаний токен. JWE (JSON Web Encryption) — зашифрований токен, де корисне навантаження не можна прочитати без ключа дешифрування. Більшість JWT є токенами JWS.

Де слід зберігати JWT: у localStorage чи у cookies?

Cookies з атрибутом HttpOnly більш безпечні, оскільки вони недоступні через JavaScript (запобігаючи крадіжці через XSS). localStorage вразливий до XSS-атак. Для чутливих застосунків використовуйте cookies HttpOnly Secure SameSite.

Пов'язані інструменти