Плюси та мінуси JWT: короткий огляд тонкощів цієї технології

У цій статті представлений аналіз JWT (JSON Web Tokens, правильно вимовляється як «джот») — починаючи з того, як вони використовуються, і закінчуючи плюсами та мінусами використання JWT у вашому додатку. Останнім часом автентифікація за допомогою JWT стала неймовірно популярна, тим часом, багато програмістів-початківців не до кінця розуміють, що крім очевидних плюсів у цього підходу є й мінуси. Ми спробували максимально візуалізувати схеми та логіки роботи авторизації, щоб наш аналіз був максимально зрозумілим та простим для читача.

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

Один із способів опису JWT полягає в тому, що він є «перенесеними одиницями ідентифікації». Це означає, що токени містять інформацію про ідентифікацію у форматі JSON і можуть універсальним способом передаватись службам та додаткам. Будь-який сервіс або програма може самостійно перевірити JWT. Служба/додаток, що отримує JWT, не має запитувати постачальника ідентифікаційних даних, який створив JWT, чи дійсний він. Після перевірки JWT-служба або програма може використовувати дані, що містяться в ньому, для виконання дій від імені користувача.

Ось загальна діаграма, що ілюструє, як постачальник ідентифікаційних даних створює JWT, і як служба може використовувати JWT, не звертаючись до постачальника ідентифікаційних даних (так, на діаграмі зображено Palm Pilot):

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

Ось діаграма, що ілюструє, як викликається постачальник ідентифікаційних даних для перевірки непрозорого токена та для отримання даних користувача:

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

Є кілька моментів, які слід враховувати під час ухвалення рішення про використання JWT. Давайте розглянемо кілька основних із них.

Термін дії JWT спливає через певні проміжки часу

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

Традиційні сесії авторизації завжди мають певну тривалість з часу останньої взаємодії з користувачем. Це означає, що якщо користувач натискає кнопку, його сесія продовжується. Якщо згадати більшість додатків, якими ви користуєтеся, це досить поширене явище. Ви автоматично виходите з програми після певного часу бездіяльності.

Дія токенів JWT, з іншого боку, не подовжуються при взаємодії з користувачем. Натомість вони програмно замінюються шляхом створення нового JWT для користувача, причому все відбувається прозоро та у фоновому режимі.

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

JWT підписуються

Оскільки JWT підписані криптографічно, для їх перевірки знадобиться аналогічний криптографічний алгоритм. Криптографічні алгоритми спеціально розробляються так, аби бути повільними. Чим повільніше алгоритм, тим вища складність і менша ймовірність того, що алгоритм можна зламати методом перебору (brute force).

На чотириядерному MacBook Pro можна створити та підписати близько 200 JWT на секунду за допомогою RSA з відкритим та закритим ключем. Це число різко знижується на віртуалізованому устаткуванні, такому як Amazon EC2s. Підписання HMAC набагато швидше, але не має такої ж гнучкості та характеристик безпеки.

Зокрема, якщо постачальник ідентифікаційних даних використовує HMAC для підписання JWT, всі служби, які хочуть перевірити JWT, повинні мати секрет HMAC. Це означає, що всі служби тепер також можуть створювати та підписувати JWT. Це робить JWT менш переносимими (зокрема, для публічних служб) та менш безпечними.

Щоб дати вам уявлення про характеристики продуктивності JWT і використовувані криптографічні алгоритми, ми провели кілька тестів на чотириядерному MacBook. Ось виміри, які ми отримали за масового створення JWT (у форматі метрика/таймінг):

• Серіалізація JSON + кодування Base64 — 400,000/s
• Серіалізація JSON + кодування Base64 + підписання HMAC — 150,000/s
• Серіалізація JSON + кодування Base64 + підписання RSA — 200/s
• Декодування Base64 + Парсинг JSON — 400,000/s
• Декодування Base64 + Парсинг JSON + Перевірка HMAC – 130,000/s
• Декодування Base64 + парсинг JSON + верифікація RSA — 6,000/s

JWT не можна легко відкликати

Це означає, що JWT може бути дійсним, навіть якщо обліковий запис користувача було припинено або видалено. Є кілька способів обійти це, включаючи «подію відкликання оновленого токена» у поєднанні з webhook. Це рішення, наприклад, доступне в FusionAuth.

JWT мають вразливості

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

Обидві ці атаки мають прості виправлення. Зокрема, ви ніколи не повинні дозволяти JWT, які створені за допомогою алгоритму «none». Також не слід сліпо завантажувати ключі/підписи, використовуючи заголовок «kid» в JWT. Натомість слід додатково перевірити, що ключ дійсно є правильним ключем для алгоритму, вказаному у заголовку.

Сесії як альтернатива

Замість використання JWT або непрозорих токенів, у вас завжди є можливість використовувати сесії. Сесії існують вже понад два десятиліття і є перевіреною технологією. Сесії зазвичай працюють за допомогою файлів cookie та стану, що зберігається на боці сервера. Cookie містить рядок символів, який є ідентифікатором сесії. Сервер містить великий хеш, де зберігаються довільні дані.

Коли користувач входить до системи, об’єкт користувача зберігається в сесії, а сервер відправляє сесійний файл cookie, що містить ідентифікатор сесії. Кожен наступний запит на сервер включає індивідуальний файл cookie для цієї сесії. Сервер використовує файл cookie для завантаження об’єкта користувача із сесії Hash. Потім об’єкт користувача використовується для ідентифікації користувача, який зробив запит. Ось дві діаграми, що ілюструють цю концепцію:

 

Якщо у вас невелика програма, яка використовує один бекенд, сесії працюють добре. Як тільки ви починаєте масштабуватися або використовувати мікросервіси, сеанси можуть стати складнішим завданням.

Найбільші архітектури вимагають балансування навантаження та прив’язки сесій, коли кожен клієнт прив’язується до певного сервера, на якому зберігається його сесія. Реплікація сеансів або розподілений кеш може бути потрібен для забезпечення відмовостійкості або оновлення без простою. Навіть з урахуванням цієї додаткової складності, сесії все ще можуть бути гарним варіантом, якщо ви готові ускладнювати логіку реалізації подібним чином.

Підбиття підсумків

Я сподіваюся, що цей короткий огляд JWT і сесій був корисний і пролив світло на ці технології, які використовуються для ідентифікації та управління користувачами. Будь-яке з цих рішень працюватиме практично в будь-якому додатку. Вибір зазвичай зводиться до ваших потреб, мов та фреймворків.

Наприкінці ще раз варто зазначити, що за замовчуванням JWT не шифруються (режим none), і що рядок, який ми бачимо, є просто серіалізацією в кодуванні base64url, яку можна легко декодувати, щоб побачити звичайний вміст JSON, який несе токен.

Тому відповідь на первісне питання статті про безпеку JWT звучить так: «Це залежить від…». Як і багато інших технологій, JWT значною мірою залежить від хорошої конфігурації при випуску токенів, а також від правильного використання та коректної валідації споживаних ззовні токенів.

Для автоматизації тестів безпеки для JWT можна запропонувати спеціалізований проект з відкритим вихідним кодом. На даний момент він складається з двох утиліт:

• APICheck складається з набору невеликих інструментів, які можуть бути з’єднані в ланцюг для виконання кількох тестів на API-запити.
• Після цього ми також зайнялися розробкою нового інструменту перевірки JWT, jwt-checker , в якому реалізували можливість проходження перевірки на коректність токенів.