#Безпека

JSON Web Token припинили бути модною технологією ще, мабуть, років 5 тому, але тепер вони стали чимсь таким звичним, що наче має сенс для автентифікації. Зокрема, вони “вигідно” відрізняються від просто випадкового ключа сесії тим, що всередину можна запхати якісь дані, та ще і якась криптографія присутня, тож це ж, мабуть, ще й безпечніше?

Ні. Головне, що треба усвідомити - JWT не є зашифрованим, а тільки підписаним! Який ти алгоритм не обирай для створення JWT, це впливає тільки на зміст підпису. Дані ж лише закодовані в Base64 - певно, щоб полегшити транспортування. (Власне, JWT складається з трьох рядків у Base64, зʼєднаних крапками: заголовок, зміст, підпис.)

Тому у JWT не можна класти ніякі секретні дані. Можна думати про JWT як квиток на концерт: на ньому зазначене твоє місце, а також є печатка каси. На концерті білетер — вже без каси! - може перевірити печатку та пропустити тебе в зал. В цьому і є весь зміст існування JSON Web Token.

Так само для JWT є тільки одне місце: коли треба передати не дуже таємні дані з одного сервісу в інший через відкритий канал. Типове використання — якщо в складній інфраструктурі авторизацією займається окремий сервіс. Тоді у JWT сидить ID користувача та, можливо, інші необхідні атрибути — можливо, навіть права доступу.

Практично обовʼязково JWT повинний мати термін дійсності, бо він є самодостатнім носієм інформації, та його неможливо відкликати (а якщо технічно можливо, то ймовірно, JWT в такій архітектурі зайві.)

Що краще взяти замість JWT? На мою думку, кукі з ключем сесії та HttpOnly все ще ідеальний варіант, якщо ми можемо його собі дозволити.

🥠 Кукі були потрібні до епохи JavaScript, коли серверу потрібно було якось зберігати дані на клієнті. Звісно, зараз у нас на клієнті повноцінні застосунки, тож кому ті архаїчні кукі потрібні?

Втім, насправді в кукі вбудовано багато механізмів захисту, та не всі з них ми взагалі можемо відтворити. Головним чином, це атрибут HttpOnly - кукі з HttpOnly не доступні для клієнтського коду, їх наче немає. А значить, їх неможливо вкрасти ніякою інʼєкцією коду. Що, до речі, чи не найбільш реалістична атака на ваш сайт.

Окрім того, в кук є ще низка атрибутів, яка допомагає захистити їх від помилок - CSRF, пересилання без шифрування тощо. Одним словом, безпека кук — це функція браузера, та нам не потрібно (та не варто) придумувати власні альтернативи.

(Примітка: вкрасти куки через злам браузера або локальний доступ до нього — звісно, можливо. Тільки це не так ймовірно, як інʼєкція.)

До речі, fetch() підтримує кукі, причому опціонально навіть якщо API не на тому ж домені. Єдине, що хтось з того домену повинен куку встановити. На відміну від саморобних токенів, кукі також надсилаються для зображень та інших ресурсів.

По змісту в кук немає різниці з будь-якими іншими токенами — туди можна записати будь-що. Але для автентифікації можна виділити два варіанти: або це випадковий токен, що вказує на стан на сервері, або токен зі змістом.

Мені подобається зберігати стан на сервері, бо це робить кукі повністю непрозорими та не потребує складних механізмів приховування та верифікації змісту. Та й розмір стану на сервері практично не обмежений. (Ось відповідь на Stack Exchange, де про це розповідає.)