печенье против сессии против JWT

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

• Cookie-файлы: в ранней версии текстовый файл с уникальным клиентом идентифицировал всю остальную информацию, необходимую для клиента (например, роли)

• Сессия: в файл отправляется только уникальный идентификатор клиента (также называемый cookie), все остальное хранится на сервере

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

Спасибо за любые отзывы!

Cookie-файлы: в ранней версии текстовый файл с уникальным клиентом идентифицировал всю остальную информацию, необходимую для клиента (например, роли)

Файлы cookie - это кортежи, key-valueизначально предназначенные для хранения данных, связанных с деятельностью клиента. Это сохранение - это то, что мы знаем как состояние сеанса или приложения . По сути, они были сделаны для удержания состояния веб-приложений; более конкретно, состояние на стороне клиента. ⁽¹⁾

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

О куки-файлах важно знать, что они не идентифицируют пользователей. Они скорее связывают данные терна - клиент - сервер / путь . ⁽³⁾

Мы обычно связываем файлы cookie с файлами, потому что в первые дни работы веб-браузеров им приходилось каким-то образом сохранять файлы cookie, поскольку файлы были наиболее реальной поддержкой. Современные браузеры хранят файлы cookie (помимо прочего) в локальных хранилищах (встроенных БД).

Сеанс: в файл отправляется только уникальный идентификатор клиента (также называемый cookie), все остальное хранится на сервере.

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

В любом случае идентификатор сеанса не обязательно идентифицирует пользователя. Он связывает определенное состояние приложения с веб-клиентом. Сессии могут содержать или не содержать пользовательские данные.

В распределенных приложениях сеанс должен быть сериализуемым по очевидным причинам. Если они хранятся в памяти, хранилище в памяти (компонент) должно быть сериализуемым. Распространенным решением является хранение сессий в файлах. Или в NoSQL DB, как Redis.

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

С другой стороны, атака на инфраструктуру на стороне сервера не является тривиальной.

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

На самом деле, нет. JWT хранит данные, в основном связанные с авторизацией и эмитентом токена.

Хотя они и содержат идентификатор пользователя (sub), мы находим JWT, которые не идентифицируют аутентифицированных пользователей. Например, токены для гостей сеансов. Основным содержанием JWT являются претензии ; элементы для проверки в процессе авторизации.

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

Что касается JWT, они часто хранятся в виде файлов cookie, хотя они также могут храниться в локальных хранилищах. Более того, сообщество OWASP считает sessionStorage более безопасным для веб-браузеров. Однако это зависит от версии браузера .

1: Всемирная паутина предназначена для лиц без гражданства. Если мы хотим создавать серверные приложения без сохранения состояния, сеансы должны храниться где-то на стороне клиента.

2: Превращение приложения на стороне сервера в приложение с сохранением состояния .

3: Клиент как приложение, а не как пользователь.

Cookie-файлы: в ранней версии текстовый файл с уникальным клиентом идентифицировал всю остальную информацию, необходимую для клиента (например, роли)

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

Пример обмена файлами cookie выглядит следующим образом:

Сессия: в файл отправляется только уникальный идентификатор клиента (также называемый cookie), все остальное хранится на сервере

Это в значительной степени верно. Сеанс - это данные, которые хранятся на стороне сервера о текущем сеансе пользователя. Чтобы это работало в протоколе без сохранения состояния, таком как HTTP, пользователь должен отправлять свой идентификатор сеанса с каждым запросом, чтобы сервер мог выбрать правильный сеанс для пользователя. Идентификатор сеанса обычно хранится в файле cookie (см. Выше). Это не другой файл cookie, чем любой другой файл cookie, данные - это просто идентификатор сервера для сеанса пользователя.

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

Это в значительной степени правда. Все хранится в токене. Токен может быть сохранен в куки (см. Выше). Это альтернатива серверным сеансам, и она работает, потому что токен подписан и проверен сервером, поэтому его нельзя изменить или подделать, и его можно безопасно хранить на стороне клиента.