cookie vs. session vs jwt

Я читаю про автентифікацію / авторизацію у веб-додатках. Чи може хтось підтвердити / виправити мої поточні знання?

• Файли cookie: у їх ранній версії текстовий файл з унікальним клієнтом Id та вся інша інформація, необхідна про клієнта (наприклад, ролі)

• Сесія: у файл надсилається лише унікальний ідентифікатор клієнта (також званий cookie), а все інше зберігається на сервері

• JWT: все зберігається в маркері (який також може бути збережений у текстовому файлі, який також називається cookie)

Дякуємо за будь-які відгуки!

Файли cookie: у їх ранній версії текстовий файл з унікальним клієнтом Id та вся інша інформація, необхідна про клієнта (наприклад, ролі)

Файли cookie - це кортежі, key-valueспочатку адресовані для збереження даних, що стосуються діяльності клієнта. Це утримання - це те, що ми знаємо як сеанс або стан програми . По суті, вони були зроблені для зберігання стану веб-додатків; конкретніше, стан на стороні клієнта. ⁽¹⁾

Файли cookie зазвичай встановлюються сервером через заголовки відповідей ( Set-Cookie key=value). Однак їх може встановити і клієнт. Наприклад, DOM ( document.cookie).

Важливо знати про файли cookie - це те, що вони не ідентифікують користувачів. Вони швидше асоціюють дані terna - клієнт - сервер / шлях . ⁽³⁾

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

Сесія: у файл надсилається лише унікальний ідентифікатор клієнта (також званий cookie), а все інше зберігається на сервері.

Під сеансом, я думаю, ви маєте на увазі сеанси сервера . Як я коментував, сеанси можуть бути реалізовані і на стороні клієнта. Відмінність від сеансів на стороні клієнта полягає в тому, що дані зберігаються десь на стороні сервера. ⁽²⁾ У таких сценаріях ми отримуємо ідентифікатор сеансу; і ми отримуємо його у формі печива. Без ідентифікатора сеансу сервер не зміг би співставити вхідні запити з попередньою діяльністю клієнта. (3) Наприклад, автентифікований користувач, кошик для покупок тощо.

У будь-якому випадку ідентифікатор сеансу не обов'язково ідентифікує користувача. Він пов'язує конкретний стан програми з веб-клієнтом. Сесії можуть містити або не містити даних користувачів.

У розподілених додатках сеанс повинен бути серіалізаційним із зрозумілих причин. Якщо вони зберігаються в пам'яті, запам'ятовуючий компонент (компонент) повинен бути серіалізаційним. Поширене рішення - зберігати сеанси у файлах. Або в NoSQL БД, як Redis.

Щодо безпеки. Сеанси на стороні сервера безпечніші, ніж на стороні клієнта. Клієнти вразливіші до загроз, оскільки користувачі зазвичай не знають про стільки загроз, яким вони піддаються. Принаймні, не звичайний користувач.

З іншого боку, атакувати серверну інфраструктуру не є рівнозначним.

JWT: все зберігається в маркері (який також може бути збережений у текстовому файлі, який також називається cookie)

Не зовсім. JWT зберігає дані, в основному пов'язані з авторизацією та видачею маркера.

Хоча вони містять ідентифікатор користувача (суб), ми знаходимо JWT, які не ідентифікують автентифікованих користувачів. Наприклад, жетони для відвідувачів сеансів. Основним змістом JWT є претензії ; елементи, які перевіряються процедурою авторизації.

Важливо пам’ятати, що JWT не є глобальними сховищами . Сесія або стан додатки до сих пір де - то зберігати і управляти незалежно один від одного.

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

1: Всесвітня павутина покликана бути без громадянства. Якщо ми хочемо створити програми без стану сервера, сеанси повинні зберігатися десь на стороні клієнта.

2: Включення серверної частина програми в динамічне додаток.

3: Клієнт як додаток, а не як користувач.

Файли cookie: у їх ранній версії текстовий файл з унікальним клієнтом Id та вся інша інформація, необхідна про клієнта (наприклад, ролі)

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

Приклад обміну файлами cookie виглядає приблизно так:

Сесія: у файл надсилається лише унікальний ідентифікатор клієнта (також званий cookie), а все інше зберігається на сервері

Це майже правильно. Сеанс - це дані, які зберігаються на стороні сервера про поточний сеанс користувача. Щоб зробити цю роботу за протоколом без стану, як HTTP, користувач повинен надсилати свій ідентифікатор сеансу з кожним запитом, щоб сервер міг отримати правильний сеанс для користувача. Ідентифікатор сеансу зазвичай зберігається у файлі cookie (див. Вище). Це не інший файл cookie, ніж будь-який інший файл cookie, дані - це лише ідентифікатор сервера для сеансу користувача.

JWT: все зберігається в маркері (який також може бути збережений у текстовому файлі, який також називається cookie)

Це майже правда. Все зберігається в маркері. Маркер може зберігатися у файлі cookie (див. Вище). Це альтернатива сеансам сервера, і вона працює, тому що маркер підписаний і перевірений сервером, тому його неможливо змінити і не підробити, і зберігати на стороні клієнта безпечно.