Я читал несколько сообщений о "JWT vs Cookie", но они только сбили меня с толку ...

1. Я хочу пояснить , когда люди говорят о «аутентификации на основе токенов или куки», куки здесь просто относятся к куки сеанса ? Я понимаю, что 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 (JWT) от клиента на сервер.

И файлы cookie, и токены-носители отправляют данные.

Одно из отличий заключается в том, что файлы cookie предназначены для отправки и хранения произвольных данных, тогда как токены-носители предназначены специально для отправки данных авторизации.

Эти данные часто кодируются как JWT.

Cookie-файлы

Файл cookie - это пара «имя-значение», которая хранится в веб-браузере и имеет дату истечения срока действия и связанный домен.

Мы храним файлы cookie в веб-браузере с помощью JavaScript или заголовка HTTP-ответа.

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 в этом случае использования, но вы теряете библиотеки и коллегиальную проверку стандарт, в дополнение к вопросам CSRF, о которых говорилось в другом ответе.

В итоге: сообщения, которые вы читаете, вероятно, сравнивают JWT в качестве токена-носителя с файлом cookie аутентификации для целей аутентификации браузера и сервера. Но JWT может делать гораздо больше, он вносит стандартизацию и функции для использования вне того варианта использования, о котором вы, вероятно, думаете.

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

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

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

Ссылка - Необходимость в веб-токене JSON

Печенье

В случае файлов cookie, как только пользователь будет аутентифицирован, сервер Gmail создаст уникальный идентификатор сеанса. В соответствии с этим идентификатором сеанса он будет хранить в памяти всю информацию о пользователе, которая необходима серверу Gmail для распознавания пользователя и выполнения операций.
Также для всех последующих запросов и ответов этот идентификатор сеанса также будет передан. Итак, теперь, когда сервер получает запрос, он проверяет идентификатор сеанса. Использование этого идентификатора сеанса позволит проверить, есть ли соответствующая информация. Затем он позволит пользователю получить доступ к ресурсу и вернуть ответ вместе с идентификатором сеанса.

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

• Файлы cookie / идентификатор сеанса не являются автономными. Это ссылочный токен. Во время каждой проверки серверу Gmail необходимо получить соответствующую ему информацию.
• Не подходит для архитектуры микросервисов, включающей несколько API и серверов.

JWT

• JWT самодостаточен. Это токен стоимости. Таким образом, во время каждой проверки серверу Gmail не нужно получать соответствующую ему информацию.
• Он имеет цифровую подпись, поэтому, если кто-то изменит его, сервер узнает об этом.
• Он наиболее подходит для архитектуры микросервисов.
• У него есть и другие преимущества, такие как указание срока годности.