У цій статті
Що таке JWT?
JSON Web Token (JWT) — це компактний, безпечний для URL формат токенів, який використовується для безпечної передачі інформації між сторонами у вигляді JSON-об'єкта. JWT складається з трьох частин, закодованих у Base64URL та розділених крапками: заголовок.корисне-навантаження.підпис. Заголовок вказує алгоритм підпису, корисне навантаження містить заяви (дані), а підпис перевіряє, що токен не було змінено.
JWT забезпечують аутентифікацію без збереження стану — серверу не потрібно зберігати дані сесії, оскільки вся необхідна інформація вбудована в сам токен. Це робить JWT ідеальними для розподілених систем, мікросервісів та API, де зберігання сесій додало б складності та затримки.
Структура JWT
Кожен JWT складається з трьох окремих частин, кожна з яких відіграє певну роль у життєвому циклі токена:
- Заголовок (Header) — JSON-об'єкт, що вказує тип токена (typ: JWT) та алгоритм підпису (alg: HS256, RS256 тощо), потім кодується у Base64URL
- Корисне навантаження (Payload) — JSON-об'єкт із заявами: iss (видавець), sub (суб'єкт), exp (термін дії), iat (дата видачі) та будь-які користувацькі дані
- Підпис (Signature) — створюється шляхом підписання закодованих заголовка та корисного навантаження секретним ключем (HMAC) або приватним ключем (RSA/ECDSA), забезпечуючи цілісність токена
Корисне навантаження не зашифроване — будь-хто може його декодувати та прочитати. Ніколи не зберігайте конфіденційну інформацію, таку як паролі чи номери кредитних карток, у корисному навантаженні JWT. Підпис лише гарантує, що дані не були змінені, а не що вони приховані.
Алгоритми підпису
Вибір алгоритму підпису визначає, як створюється та перевіряється підпис JWT. Існують три основні сімейства алгоритмів:
- HMAC (HS256, HS384, HS512) — симетричні алгоритми, що використовують один і той самий секретний ключ для підпису та перевірки. Прості у впровадженні, найкращі для конфігурацій з одним сервером
- RSA (RS256, RS384, RS512) — асиметричні алгоритми, що використовують приватний ключ для підпису та публічний ключ для перевірки. Ідеальні для розподілених систем
- ECDSA (ES256, ES384, ES512) — асиметричні алгоритми на основі криптографії еліптичних кривих. Забезпечують таку ж безпеку, як RSA, з меншими розмірами ключів та швидшими обчисленнями
Для більшості веб-додатків HS256 достатньо, коли видавець і споживач токена — один і той самий сервер. Обирайте RS256 або ES256, коли токени потрібно перевіряти третім сторонам або між різними сервісами.
Спробуйте безкоштовно — реєстрація не потрібна
Створити та підписати JWT →Кодування та декодування
Кодування JWT означає створення нового токена шляхом збирання заголовка, корисного навантаження та генерації підпису за допомогою вашого секретного або приватного ключа. Зазвичай це виконується на стороні сервера під час входу або оновлення токена.
Декодування JWT може означати дві речі: вилучення заяв корисного навантаження без перевірки підпису (корисно для читання метаданих токена на клієнті), або повну перевірку підпису для підтвердження автентичності токена. Виробничі системи повинні завжди перевіряти підпис перед тим, як довіряти заявам у корисному навантаженні.
Поширені випадки використання
JWT стали стандартом для сучасних моделей аутентифікації та авторизації у веб- та мобільних додатках:
- Аутентифікація API — клієнти включають JWT у заголовок Authorization (Bearer token) з кожним запитом, дозволяючи серверу перевіряти ідентичність без звернень до бази даних
- Токени доступу OAuth 2.0 — провайдери OAuth видають JWT як токени доступу, що містять інформацію про область та дозволи для авторизованого доступу до API
- Комунікація між мікросервісами — сервіси передають JWT один одному для поширення ідентичності користувача та дозволів через межі сервісів без централізованого зберігання сесій
- Єдиний вхід (SSO) — центральний провайдер ідентичності видає JWT, який приймають кілька додатків, дозволяючи користувачам аутентифікуватися один раз і отримувати доступ до всіх підключених сервісів
Найкращі практики безпеки
JWT потужні, але потребують ретельної реалізації для уникнення поширених пасток безпеки:
- Встановлюйте короткі терміни дії — використовуйте заяви exp від 15 хвилин до 1 години для токенів доступу та впроваджуйте ротацію токенів оновлення для довших сесій
- Ніколи не зберігайте конфіденційні дані у корисному навантаженні — корисне навантаження JWT лише закодоване у Base64URL, а не зашифроване
- Завжди перевіряйте всі заяви — перевіряйте exp, iss, aud та будь-які користувацькі заяви при кожному запиті
- Використовуйте виключно HTTPS — передавайте JWT лише через зашифровані з'єднання для запобігання перехопленню токенів
- Відхиляйте алгоритм "none" — завжди перевіряйте, що заголовок alg відповідає вашому очікуваному алгоритму
Часті запитання
Яка різниця між JWT та сесійними cookies?
Сесійні cookies зберігають ідентифікатор сесії на клієнті, а фактичні дані сесії знаходяться на сервері. JWT є автономними — всі дані містяться в самому токені. Це робить JWT без збереження стану та легшими для горизонтального масштабування, але складнішими для відкликання.
Як відкликати JWT до його закінчення?
Оскільки JWT є без збереження стану, вбудованого механізму відкликання немає. Поширені стратегії включають: ведення чорного списку токенів, використання короткоживучих токенів доступу з ротацією токенів оновлення або зберігання версії токена в записі користувача.
Чи є обмеження розміру для JWT?
Формального обмеження розміру в специфікації JWT немає, але існують практичні обмеження. Більшість HTTP-серверів обмежують розмір заголовків до 8 КБ. Оскільки JWT зазвичай надсилаються в заголовку Authorization, рекомендується тримати токени менше 4 КБ.