Я прочитав кілька публікацій про "JWT vs Cookie", але вони лише збентежили мене ...

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

2. Для чого нам потрібен веб-маркер JSON ? Я використовував стандартний файл cookie для реалізації аутентифікації на основі лексеми ( не використовуючи ідентифікатор сеансу, не використовую пам'ять сервера або зберігання файлів ): Set-Cookie: user=innocent; preferred-color=azureі єдина відмінність, яку я зауважила, це те, що JWT містить як корисне навантаження, так і підпис ... тоді як ви можете вибрати між підписаним чи простим текстом cookie для заголовка http. На мій погляд, підписане cookie ( cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM') є більш просторовим, єдиний недолік полягає в тому, що клієнт не може прочитати маркер, тільки сервер може ... але я думаю, що це нормально, оскільки так само, як претензія в JWT є необов'язковою, маркер не потрібно бути значущим

Найбільша відмінність між маркерами носіїв та файлами cookie полягає в тому, що браузер автоматично надсилатиме файли cookie , де маркери носія повинні бути явно додані до HTTP-запиту.

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

Браузер, який автоматично надсилає файли cookie, також має великий мінус, це CSRF- атаки. Під час атаки CSRF шкідливий веб-сайт використовує той факт, що ваш веб-переглядач автоматично додає файли cookie для аутентифікації до запитів до цього домену та наштовхує ваш браузер на виконання запиту.

Припустимо, веб-сайт за адресою https://www.example.com дозволяє автентифікованим користувачам змінювати свої паролі, POSTдодавши новий пароль на https://www.example.com/changepassword, не вимагаючи розміщення імені користувача або старого пароля.

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

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

Крім того, файли cookie ускладнюють використання API, що не працює на веб-переглядачах (наприклад, мобільні програми для планшетів).

Огляд

Те, що ви просите, - це різниця між файлами cookie та маркерами носія для надсилання JSON Web Tokens (JWT) від клієнта на сервер.

Як файли cookie, так і маркери носія надіслати дані

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

Ці дані часто кодуються як JWT.

Печиво

Файл cookie - це пара значень імен, що зберігається у веб-браузері і має дату закінчення терміну дії та пов’язаний з ним домен.

Ми зберігаємо файли cookie у веб-браузері або з JavaScript, або з заголовком HTTP Response.

document.cookie = 'my_cookie_name=my_cookie_value'   // JavaScript
Set-Cookie: my_cookie_name=my_cookie_value           // HTTP Response Header

Веб-браузер автоматично надсилає файли cookie з кожним запитом до домену файлу cookie.

GET http://www.bigfont.ca
Cookie: my_cookie_name=my_cookie_value               // HTTP Request Header

Знак носія

Маркер носія - це значення, яке надходить у Authorizationзаголовок будь-якого HTTP-запиту. Він автоматично не зберігається ніде, не має терміну придатності та асоційованого домену. Це просто цінність. Ми вручну зберігаємо це значення в наших клієнтах і вручну додаємо це значення до заголовка авторизації HTTP.

GET http://www.bigfont.ca
Authorization: Bearer my_bearer_token_value          // HTTP Request Header

Аутентифікація на основі JWT та маркера

Коли ми робимо аутентифікацію на основі лексеми, такі як OpenID, OAuth або OpenID Connect, ми отримуємо access_token (а іноді id_token) від надійного органу. Зазвичай ми хочемо зберігати його та надсилати разом із HTTP-запитами щодо захищених ресурсів. Як ми це робимо?

Варіант 1 - зберігати маркер (и) у файлі cookie. Це обробляє сховище, а також автоматично надсилає маркер (и) серверу в Cookieзаголовок кожного запиту. Потім сервер аналізує файл cookie, перевіряє маркер (и) та відповідає відповідно.

Інший варіант - зберегти маркер у локальному / сесійному сховищі, а потім вручну встановити Authorizationзаголовок кожного запиту. У цьому випадку сервер зчитує заголовок і протікає так само, як із файлом cookie.

Варто прочитати пов'язані RFC, щоб дізнатися більше.

На додаток до того, що MvdD сказав про автоматичне надсилання файлів cookie:

1. Файл cookie може бути носієм, але його найбільш важливою функцією є те, як він взаємодіє з браузером. Файли cookie встановлюються сервером і надсилаються у запитах дуже конкретними способами. З іншого боку, JWT - це виключно носій, це твердження деяких фактів у певній структурі. Якщо ви були настільки схильні, ви можете поставити JWT як ваш cookie-аутентифікацію. Коли ви читаєте статті, порівнюючи їх, вони, як правило, говорять про використання JWT, надісланого як маркер носія за допомогою коду переднього кінця, а також файлу cookie аутентифікації, який відповідає деякому кешованому сеансу або даним користувачам на зворотному кінці.
2. JWT пропонує безліч функцій і ставить їх у стандарт, щоб їх можна було використовувати між сторонами. JWT може виступати як підписане твердження деяких фактів у багатьох місцях. Файли cookie, незалежно від того, які дані ви вкладете в них або якщо ви підписуєте їх, використовуватиметься лише між браузером і певним зворотним кінцем. JWT можна використовувати від браузера до заднього кінця, між задніми кінцями, контрольованими різними сторонами (приклад OpenId Connect), або в межах сервісів зворотнього зв'язку однієї сторони. Що стосується конкретного прикладу ваших підписаних файлів cookie, ви, ймовірно, можете досягти тих же функцій ("не використовуючи ідентифікатор сеансу, не використовуючи пам'ять сервера або зберігання файлів"), як JWT у цьому випадку використання, але ви втрачаєте бібліотеки та експертну перевірку стандарт, на додаток до питань КСРР, про які йдеться в іншій відповіді.

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

Хоча файли cookie можуть збільшувати ризик атак CSRF через те, що вони автоматично надсилаються разом із запитами, вони можуть зменшити ризик атак XSS, коли встановлено HttpOnlyпрапор, оскільки будь-який сценарій, який вводиться на сторінку, не зможе прочитати печиво.

CSRF: користувач натискає на посилання (або переглядає зображення) на сайті зловмисника, через що браузер надсилає запит на сайт жертви. Якщо жертва використовує файли cookie, браузер автоматично включить файли cookie у запит, і якщо запит GET може спричинити будь-які дії, не доступні лише для читання, сайт жертви вразливий до атаки.

XSS: зловмисник вбудовує скрипт на сайт жертви (сайт жертви вразливий лише в тому випадку, якщо введення не санізовано правильно), і сценарій зловмисника може робити все, що дозволено робити на сторінці JavaScript. Якщо ви зберігаєте маркери JWT у локальному сховищі, сценарій зловмисника може прочитати ці маркери, а також надіслати ці маркери на сервер, яким вони керують. Якщо ви використовуєте файли cookie з HttpOnlyпрапором, сценарій зловмисника не зможе прочитати ваше cookie для початку. Однак, сценарій, який вони успішно вводили, все одно зможе зробити все, що може зробити Javascript, тому ви все ще можете мати IMO (тобто, поки вони не зможуть прочитати файл cookie, щоб пізніше його відправити на власний сервер для використання , вони можуть надсилати запити на сайт vicitim за допомогою XHR, до якого в будь-якому разі буде включатися файл cookie).

Ref - потреба в веб-токені JSON

Печиво

Що стосується файлів cookie, після аутентифікації користувача сервер Gmail створить унікальний ідентифікатор сеансу. Відповідно до цього ідентифікатора сеансу, він зберігатиме в пам'яті всю інформацію про користувача, яка потрібна серверу Gmail для розпізнавання користувача та дозволення йому виконувати операції.
Також тоді для всіх наступних запитів та відповідей цей ідентифікатор сеансу також буде переданий. Отже, коли сервер отримає запит, він перевірить ідентифікатор сеансу. Використання цього ідентифікатора сеансу перевірить, чи є відповідна інформація. Потім це дозволить користувачеві отримати доступ до ресурсу та повернути відповідь разом із ідентифікатором сеансу.

Недоліки файлів cookie

• Файли cookie / ідентифікатор сеансу не містять самостійно. Це опорний знак. Під час кожної перевірки сервер Gmail повинен отримати відповідну йому інформацію.
• Не підходить для архітектури мікросервісів із залученням декількох API та серверів

JWT

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