Яка перевага використання JWT над сеансами в таких ситуаціях, як аутентифікація?
Чи використовується в якості самостійного підходу або він використовується в сесії?
Яка перевага використання JWT над сеансами в таких ситуаціях, як аутентифікація?
Чи використовується в якості самостійного підходу або він використовується в сесії?
Відповіді:
JWT не має переваги від використання "сеансів" за висловом. JWT надають засоби для підтримки стану сеансу для клієнта, замість того, щоб це робити на сервері.
Що люди часто мають на увазі, запитуючи це: "Які переваги використання JWT над використанням сеансів на сервері "
Під час сеансів на стороні сервера вам доведеться або зберігати ідентифікатор сеансу в базі даних, або ж зберігати його в пам'яті і переконуватись, що клієнт завжди потрапляє на той же сервер. У обох цих є недоліки. У випадку з базою даних (або іншим централізованим сховищем) це стає вузьким місцем і річ, яку потрібно підтримувати - по суті, додатковий запит, який потрібно виконати з кожним запитом.
За допомогою рішення в пам'яті ви обмежуєте горизонтальне масштабування, а на сеанси впливатимуть проблеми з мережею (клієнти роумінгу між Wi-Fi і мобільними даними, перезавантаження серверів тощо)
Переміщення сеансу до клієнта означає, що ви усунете залежність від сеансу на сервері, але це накладає власний набір проблем.
Ці питання поділяються також JWT та іншими механізмами сеансів на стороні клієнта.
JWT, зокрема, стосується останнього з них. Це може допомогти зрозуміти, що таке JWT:
Це трохи інформації. Для сеансів користувача можна вказати ім’я користувача та час закінчення терміну дії маркера. Але це може бути будь-що, навіть ідентифікатор сеансу або весь профіль користувача. (Будь ласка, не робіть цього, хоча) Він отримав захищений підпис, який запобігає зловмисним сторонам генерувати підроблені жетони (Вам потрібен доступ до приватного ключа сервера, щоб підписати їх, і ви можете переконатися, що вони не були змінені після їх підписання). надсилайте їх із кожним запитом так само, як Authorizationбуде надіслано файли cookie або заголовка. Насправді вони зазвичай надсилаються у Authorizationзаголовку HTTP, але за допомогою файлу cookie теж добре.
Маркер підписаний і сервер може перевірити його походження. Ми будемо вважати, що сервер довіряє своїй власній здатності безпечно підписувати (ви повинні використовувати стандартну бібліотеку: не намагайтеся робити це самостійно та надійно захищайте сервер)
На питання безпечного транспортування маркера відповідь зазвичай надсилається через зашифрований канал, як правило, httpS.
Що стосується надійного зберігання маркера в клієнті, вам потрібно переконатися, що погані хлопці не зможуть дістатися до нього. Це (в основному) означає запобігання JS з поганих веб-сайтів читати токен, а також надсилати їм їх назад. Це пом'якшується за допомогою тих же стратегій, що застосовуються для пом'якшення інших видів атак XSS.
Якщо у вас є необхідність визнати недійсними JWT, напевно є способи цього досягти. Зберігання епохи на кожного користувача лише для тих користувачів, які попросили припинити свої "інші сеанси" - це дуже ефективний метод, який, ймовірно, буде досить хорошим. Якщо програмі потрібна ініціалізація за сеанс недійсної, тоді ідентифікатор сеансу можна підтримувати таким же чином, а таблицю "вбитих жетонів" все ще можна підтримувати набагато меншою, ніж повна таблиця користувачів (Вам потрібно зберігати записи, новіші ніж найдовший дозволений термін дії маркера.) Отже, можливість недійсності маркера частково заперечує перевагу сеансів на стороні клієнта, оскільки вам доведеться підтримувати стан сеансу вбитого. Це, швидше за все, буде набагато меншою таблицею, ніж оригінальна таблиця стану сеансу, тому огляди все ще ефективніші.
Ще одна перевага використання жетонів JWT полягає в тому, що це досить просто реалізувати, використовуючи бібліотеки, доступні, мабуть, на кожній мові, на яку ви можете розраховувати. Він також повністю відірваний від вашої початкової схеми автентифікації користувача - якщо ви переходите до системи, що базується на пальці, вам не потрібно вносити жодних змін у схему управління сеансом.
Більш тонка вигода: Оскільки JWT може нести "інформацію", і клієнт може отримати доступ до цього, тепер ви можете почати робити деякі розумні речі. Наприклад, нагадайте користувачеві, що їх сеанс закінчується за кілька днів до виходу з системи, надаючи їм можливість повторної аутентифікації на основі дати закінчення терміну дії в маркері. Що б ви не могли собі уявити.
Отже, коротко: JWT відповідає на деякі питання та недоліки інших методик сеансу.
Хоча JWT не відповідає на інші питання, такі як безпечне зберігання чи транспорт, вони не вводять жодних нових проблем безпеки.
Навколо JWT існує багато негативу, але якщо ви реалізуєте таку ж безпеку, що і для інших типів аутентифікації, вам буде добре.
Останнє зауваження: це також не Cookies проти жетонів. Файли cookie - це механізм зберігання та транспортування бітів інформації, який також може використовуватися для зберігання та транспортування жетонів JWT.
Коротка відповідь: Ні.
Більш довга версія:
Я реалізував JWT для управління сеансом, прочитавши цю рекомендацію в документах GraphQL :
Якщо ви не знайомі з жодним із цих механізмів аутентифікації, радимо використовувати express-jwt, оскільки це просто, не приносячи при цьому ніякої гнучкості в майбутньому.
Реалізація була дійсно простою, оскільки лише додала трохи складності. Однак через деякий час я (як і ви) почав цікавитись, які переваги. Виявляється, для JWT дуже мало (або, можливо, жодного), що стосується управління сеансами, як це детально пояснює ця публікація в блозі:
Мої два центи, які до речі додають контрасту до відомого допису в блозі joepie91.
Зважаючи на те, що сьогоднішні (та завтрашні) програми є (здебільшого) хмарними.
Є економічна вигода від аутентифікації JWT без громадянства , яка масштабується як масштаб додатків:
хмарні програми несуть вартість разом із кожним подихом .
Ця вартість зменшується, коли користувачам більше не доведеться автентифікувати "проти" магазину сеансів.
Обробка
Запуск сеансового магазину цілодобово коштує грошей.
Ви не можете піти з рішень на основі пам'яті у світі K8S, оскільки стручки є ефемерними.
Клейкі сеанси не пройдуть із тієї самої причини.
Зберігання
Зберігання даних коштує грошей. зберігання даних на SSD коштує ще більше.
Операції, пов’язані з сеансом, потрібно вирішити швидко, тому оптичний привід - це не варіант.
Введення / виведення
Деякі постачальники хмарних технологій стягують гроші за пов'язані з диском введення-виведення.
Пропускна здатність
Деякі хмарні провайдери платять за мережеву діяльність між екземплярами сервера.
Це стосується, оскільки майже певно, що API та сховище сесій - це окремі екземпляри.
Кластеризація сесійного магазину
Вартість ще більше збільшує всі вищезгадані витрати.
У мене було подібне питання, вибираючи JWT і token + кеш для автентифікації користувача.
Прочитавши ці статті, мені зрозуміло, що переваги обіцянок JWT не випереджають проблем, які він приносить. Тож маркер + кеш (Redis / Memcached) - це шлях для мене.
Auth Headers vs JWT vs Sessions - Як правильно вибрати техніку Auth для API