Пошук уроків, статей та іншого контенту
Структура JSON Web Token, потік автентифікації та найпоширеніша помилка щодо його безпеки.
HTTP — протокол без стану (stateless): сервер за замовчуванням не пам'ятає, хто зробив попередній запит. JSON Web Token (JWT) — стандартний спосіб передавати підтверджену інформацію про користувача в кожному запиті, без потреби зберігати сесію на сервері.
JWT — це рядок із трьох частин, розділених крапками: header.payload.signature. Кожна з перших двох частин — це JSON, закодований у Base64:
eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiI0MiIsInJvbGUiOiJhZG1pbiJ9.dQw4w9WgXcQ...
└──────── header ────────┘ └──────────── payload ────────────┘ └─ signature ─┘Header — метадані: алгоритм підпису (наприклад, HS256).
Payload — самі дані: userId, роль, час видачі, час закінчення дії. Ці «claims» (твердження) — не секретні.
Signature — криптографічний підпис перших двох частин секретним ключем сервера, що підтверджує: токен не підроблено.
Payload лише закодований у Base64, а не зашифрований — будь-хто може розкодувати його й прочитати вміст (спробуйте на будь-якому JWT-декодері). Signature гарантує, що payload не був змінений, але не приховує його вміст. Ніколи не кладіть паролі, номери карток чи інші секрети в payload JWT.
Користувач надсилає логін і пароль на сервер.
Сервер перевіряє облікові дані та генерує JWT, підписаний секретним ключем.
Клієнт зберігає токен (наприклад, у пам'яті чи httpOnly cookie) і додає його в заголовок Authorization кожного наступного запиту.
Сервер перевіряє підпис токена на кожному запиті — якщо підпис валідний і токен не прострочений, запит вважається автентифікованим, без звернення до бази даних сесій.
GET /api/profile
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiI0MiJ9...Оскільки сервер не зберігає стан про видані токени, немає централізованого місця, де можна позначити конкретний JWT недійсним до завершення терміну його дії — саме тому JWT зазвичай видають із коротким терміном дії (хвилини) у парі з окремим, довгостроковим refresh token, який можна відкликати на сервері.
Зберігання чутливих даних (паролі, номери карток) у payload — payload читається будь-ким без розшифрування.
Занадто довгий термін дії access-токена — компрометований токен лишається дійсним довше, ніж потрібно.
Зберігання JWT у звичайному localStorage для критичних застосунків — доступний будь-якому JavaScript-коду на сторінці, включно з потенційно шкідливим (XSS); httpOnly cookie безпечніший саме для цього сценарію.
Не перевіряти алгоритм підпису на сервері (наприклад, довіряти алгоритму, вказаному в самому header токена) — класична вразливість «alg: none», коли зловмисник підробляє токен без підпису, а сервер його все одно приймає.
JWT дозволяє серверу перевіряти автентичність запиту без централізованого сховища сесій — підпис гарантує, що payload не змінено, але сам payload не зашифрований і читається будь-ким. Короткий термін дії access-токена в парі з окремим, відкликаним на сервері refresh-токеном — стандартний спосіб компенсувати неможливість достроково скасувати вже виданий JWT.