За останнє десятиліття 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, дискусія зводиться до простого принципу: правильний інструмент для правильного завдання. Для різних сценаріїв — різні рішення.

Для сесійного управління у веб-застосунках (браузер ↔ ваш 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 хвилин без механізму відкликання — у вас є проблема безпеки, яку варто закрити до запуску продукту.

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