# JWT — не панацея: чому архітектори повертаються до сесійних cookies

> Популярний токен-стандарт масово використовують не за призначенням — і це коштує безпеки продукту

- Опубліковано: 17 червня 2026 р. (2026-06-17T07:14:34.085783+00:00)
- Розділ: Безпека AI
- На основі публікації: [HackerNews](https://gist.github.com/samsch/0d1f3d3b4745d778f78b230cf6061452)
- Видання: AiiN (https://aiin.news)
- URL: https://aiin.news/article?slug=jwt-%D0%BD%D0%B5-%D0%BF%D0%B0%D0%BD%D0%B0%D1%86%D0%B5%D1%8F-%D1%87%D0%BE%D0%BC%D1%83-%D0%B0%D1%80%D1%85%D1%96%D1%82%D0%B5%D0%BA%D1%82%D0%BE%D1%80%D0%B8-%D0%BF%D0%BE%D0%B2%D0%B5%D1%80%D1%82%D0%B0%D1%8E%D1%82%D1%8C%D1%81%D1%8F-%D0%B4%D0%BE-%D1%81%D0%B5%D1%81%D1%96%D0%B9%D0%BD%D0%B8%D1%85-cookies

---

За останнє десятиліття JSON Web Tokens перетворилися на де-факто стандарт аутентифікації у веб-застосунках. Кожен туторіал із REST API пропонує JWT як першу відповідь на питання «як зберегти стан авторизації». Простота видалась оманливою: один підписаний токен — і жодних звернень до бази даних при кожному запиті. Але нова хвиля дискусій довкола маніфесту «Stop Using JWTs» підняла незручне питання: а чи правильно ми взагалі обрали інструмент?

Проблема не в тому, що JWT погані самі собою. Проблема в тому, що їх масово використовують не там, де вони задумані. Це створює архітектурні та безпекові вразливості, які особливо болючі в AI-продуктах із складними flow аутентифікації та тисячами API-викликів на день.

Для команд, що будують AI-сервіси — від agent pipelines до SaaS-платформ — це не академічна дискусія. Це питання архітектурних рішень, які потім складно й дорого переробляти.

## Де JWT пішли не туди

JSON Web Tokens народилися для конкретного сценарію: передача claims між різними системами без необхідності звертатися до центральної бази даних при кожній перевірці. Класичний кейс — OAuth: Google видає токен, ваш сервіс верифікує його локально без зворотного запиту. Для цього JWT ідеальні.

Але розробники почали використовувати JWT для управління сесіями веб-застосунків — і тут починаються проблеми. Кілька фундаментальних обмежень роблять JWT поганим вибором для сесій:

- **Відкликати JWT неможливо** до закінчення терміну дії. Якщо токен скомпрометований — єдиний вихід вести blocklist, що перетворює «stateless» рішення на «stateful» із додатковою складністю
- **Розмір токена**: JWT із claims може бути у 5–10 разів більшим за звичайний session ID cookie
- **Хибне відчуття безпеки**: підпис JWT підтверджує лише цілісність, але не захищає від крадіжки самого токена
- **Алгоритмічні атаки**: специфікація допускає _alg: none_, що при некоректній імплементації дозволяє обійти перевірку підпису повністю

## Чому це критично саме для AI-продуктів

AI-застосунки мають специфічні вимоги, що загострюють ці проблеми. Уявіть типову архітектуру: фронтенд → API Gateway → кілька мікросервісів (LLM router, RAG service, billing) → зовнішні провайдери. JWT виглядають привабливо: один токен, всі сервіси верифікують його локально, немає центральної точки відмови.

Але на практиці виникає два сценарії, де це ламається. Перший: якщо потрібно заблокувати зловмисного користувача в реальному часі — JWT змушує або чекати до expiry, або підтримувати revocation list у Redis чи PostgreSQL. Ось і «stateless» перевага зникла. Другий: якщо JWT витікли через XSS або log injection — а в AI-системах outputs часто потрапляють у логи — у вас немає швидкого способу анулювати всі активні токени одним рухом.

Є ще ризик, специфічний для AI: довгі pipeline виклики. Якщо agent workflow виконується 10–30 хвилин, короткий термін дії JWT може призвести до помилок автентифікації посередині виконання. Обхід — збільшити термін — але це прямо посилює ризики компрометації.

## Що варто використовувати замість

[За даними HackerNews](https://gist.github.com/samsch/0d1f3d3b4745d778f78b230cf6061452), дискусія зводиться до простого принципу: правильний інструмент для правильного завдання. Для різних сценаріїв — різні рішення.

Для сесійного управління у веб-застосунках (браузер ↔ ваш API):

- HttpOnly cookies з server-side sessions — простіше, безпечніше, миттєве відкликання
- Session ID зберігається в Redis — масштабується горизонтально, дешево і передбачувано
- CSRF-захист вбудований у сучасні фреймворки: Django, Rails, FastAPI

Для machine-to-machine взаємодії (де JWT справді доречний):

- OAuth 2.0 client credentials flow із коротким терміном — не довше 15 хвилин
- API keys із HMAC-підписом для server-side викликів між сервісами
- mTLS для найвищого рівня безпеки в мікросервісній архітектурі

## Висновок AiiN

JWT не «мертві» і не «шкідливі» — вони просто неправильно застосовуються у більшості веб-проєктів. Тренд «Stop Using JWTs» — це корекція спрощення, яке виникло від масового копіювання туторіалів без розуміння оригінального контексту їх появи.

Для AI-білдерів практичний висновок такий: якщо браузер взаємодіє з вашим API — використовуйте сесійні cookies з Redis. Якщо ви видаєте токени для третіх сторін або між сервісами — JWT із коротким терміном та ротацією. Якщо ваш JWT живе довше 15 хвилин без механізму відкликання — у вас є проблема безпеки, яку варто закрити до запуску продукту.

Архітектурні рішення, ухвалені на старті, визначають технічний борг на роки вперед. Аутентифікація — саме те місце, де «просто скопіювати з туторіалу» може коштувати дуже дорого.

---

Теги: JWT, WebSecurity, Безпека, Authentication, AIінфраструктура, DevSec

Джерело: AiiN — https://aiin.news/article?slug=jwt-%D0%BD%D0%B5-%D0%BF%D0%B0%D0%BD%D0%B0%D1%86%D0%B5%D1%8F-%D1%87%D0%BE%D0%BC%D1%83-%D0%B0%D1%80%D1%85%D1%96%D1%82%D0%B5%D0%BA%D1%82%D0%BE%D1%80%D0%B8-%D0%BF%D0%BE%D0%B2%D0%B5%D1%80%D1%82%D0%B0%D1%8E%D1%82%D1%8C%D1%81%D1%8F-%D0%B4%D0%BE-%D1%81%D0%B5%D1%81%D1%96%D0%B9%D0%BD%D0%B8%D1%85-cookies. Цитуючи, посилайтесь на канонічний URL.