JSON Web Token (JWT) — це відкритий стандарт (RFC 7519) для безпечної передачі інформації між сторонами у вигляді JSON-об'єкта. JWT широко використовується для аутентифікації та авторизації в сучасних веб-додатках та API. У цій статті ми детально розглянемо, як працюють JWT токени, з чого вони складаються та як їх безпечно використовувати.
Що таке JWT?
JWT (вимовляється "джот") — це компактний, URL-безпечний спосіб представлення claims (тверджень) між двома сторонами. Токен складається з трьох частин, розділених крапками: Header.Payload.Signature. Кожна частина закодована в Base64URL.
На відміну від традиційних сесій, де сервер зберігає стан користувача, JWT є stateless — вся необхідна інформація міститься всередині самого токена. Це робить JWT ідеальним для розподілених систем та мікросервісної архітектури.
Структура JWT токена
Header (Заголовок)
Заголовок зазвичай містить два поля: тип токена (typ) та алгоритм підпису (alg). Найпоширеніші алгоритми — це HS256 (HMAC з SHA-256) та RS256 (RSA з SHA-256).
Приклад заголовка:
{
"alg": "HS256",
"typ": "JWT"
}Payload (Корисне навантаження)
Payload містить claims — твердження про користувача та додаткові метадані. Існує три типи claims:
- Registered claims — стандартні поля:
iss(видавець),exp(термін дії),sub(суб'єкт),aud(аудиторія),iat(час створення) - Public claims — визначені в реєстрі IANA або мають URI для уникнення колізій
- Private claims — довільні поля, узгоджені між сторонами (наприклад,
user_id,role)
Приклад payload:
{
"sub": "1234567890",
"name": "John Doe",
"role": "admin",
"iat": 1516239022,
"exp": 1516242622
}Signature (Підпис)
Підпис створюється шляхом кодування Header та Payload в Base64URL, об'єднання їх крапкою та підписування за допомогою секретного ключа. Підпис гарантує, що токен не був змінений після створення.
Для HS256 формула виглядає так:
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)Як працює аутентифікація через JWT
Процес аутентифікації з JWT зазвичай виглядає так:
- Логін: Користувач відправляє свої облікові дані (email + пароль) на сервер
- Генерація токена: Сервер перевіряє дані і, якщо вони правильні, створює JWT з потрібними claims
- Збереження: Клієнт зберігає токен (зазвичай в localStorage або httpOnly cookie)
- Відправка запитів: При кожному запиті клієнт додає токен у заголовок
Authorization: Bearer <token> - Верифікація: Сервер перевіряє підпис токена та витягує дані користувача з payload
Переваги JWT
- Stateless: Сервер не потребує зберігання сесій в базі даних або пам'яті
- Масштабованість: Ідеально підходить для мікросервісів — будь-який сервіс може верифікувати токен
- Кросдоменність: JWT легко використовувати між різними доменами та сервісами
- Компактність: Невеликий розмір дозволяє передавати токен в URL, POST-параметрах або заголовках
- Самодостатність: Вся інформація для авторизації міститься в токені
Безпека JWT: найкращі практики
1. Завжди встановлюйте термін дії
Ніколи не створюйте токени без exp claim. Рекомендований час життя access token — від 15 хвилин до 1 години. Для довших сесій використовуйте refresh tokens.
2. Використовуйте httpOnly cookies
Замість localStorage краще зберігати JWT в httpOnly cookies, які недоступні для JavaScript. Це захищає від XSS-атак. Додатково встановіть прапорці Secure та SameSite.
3. Не зберігайте чутливі дані в payload
Payload лише закодований в Base64, а не зашифрований. Будь-хто може декодувати його. Ніколи не додавайте паролі, номери кредитних карток чи інші чутливі дані.
4. Використовуйте надійні алгоритми
Уникайте алгоритму none. Для симетричного підпису використовуйте HS256 з довгим секретом (мінімум 256 біт). Для асиметричного — RS256 або ES256.
5. Валідуйте всі claims
При верифікації токена завжди перевіряйте: exp (не протермінований), iss (правильний видавець), aud (правильна аудиторія). Не довіряйте токену лише за наявністю валідного підпису.
6. Реалізуйте відкликання токенів
Хоча JWT stateless, іноді потрібно відкликати токен (наприклад, при logout або зміні пароля). Для цього використовуйте чорний список (blacklist) токенів або короткий час життя з refresh tokens.
Типові помилки при роботі з JWT
- Відсутність перевірки підпису — найнебезпечніша помилка, що дозволяє підробити токен
- Використання слабкого секрету — короткі або передбачувані секрети можна підібрати brute force
- Зберігання в localStorage — вразливість до XSS-атак
- Занадто довгий термін дії — збільшує вікно атаки при компрометації токена
- Передача через URL — токен може потрапити в логи сервера та історію браузера
JWT vs Сесії: коли що використовувати
JWT найкраще підходить для:
- Одностронікових додатків (SPA) з окремим API
- Мікросервісної архітектури
- Мобільних додатків
- Систем з single sign-on (SSO)
Традиційні сесії краще для:
- Серверних веб-додатків (Laravel, Rails, Django)
- Додатків, де потрібне негайне відкликання доступу
- Простих проектів без складної архітектури
Практика: декодування JWT
Хочете подивитися, що всередині JWT токена? Скористайтеся нашим JWT декодером — він розбирає токен на складові, показує Header, Payload та перевіряє підпис. Це корисний інструмент для розробників під час відлагодження аутентифікації.
Висновок
JWT токени — потужний механізм аутентифікації для сучасних додатків. Вони забезпечують stateless авторизацію, легко масштабуються та працюють між різними сервісами. Головне — дотримуватися правил безпеки: встановлювати термін дії, використовувати надійні алгоритми, зберігати токени безпечно та валідувати всі claims. При правильному використанні JWT значно спрощує архітектуру та покращує продуктивність додатка.
