JWT против куки для аутентификации на основе токенов

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

  1. Я хочу пояснить: когда люди говорят о "аутентификации на основе токенов против файлов cookie", здесь файлы cookie просто относятся к файлам cookie сеанса? Насколько я понимаю, cookie - это как среда, его можно использовать для реализации аутентификации на основе токенов (хранить что-то, что может идентифицировать вошедшего в систему пользователя на стороне клиента) или аутентификации на основе сеанса (хранить константу на стороне клиента которая соответствует информации о сеансе на стороне сервера)

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

6 ответов

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

Эта функция делает файлы 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 предназначены для отправки и хранения произвольных данных, тогда как токены на предъявителя предназначены специально для отправки данных авторизации.

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

печенье

Файл 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, проверяет токены и отвечает соответствующим образом.

Другой вариант - сохранить токен в локальном хранилище / хранилище сессии, а затем вручную установить Authorization заголовок каждого запроса. В этом случае сервер читает заголовок и продолжает работу, как с файлом cookie.

Стоит прочитать связанные RFC, чтобы узнать больше.

В дополнение к тому, что MvdD сказал о том, что куки автоматически отправляются:

  1. Файл cookie может быть средним, но его наиболее важной функцией является взаимодействие с браузером. Cookie-файлы устанавливаются сервером и отправляются в запросах очень конкретными способами. JWT, с другой стороны, исключительно среда, это утверждение некоторых фактов в определенной структуре. Если бы вы были так склонны, вы могли бы добавить JWT в качестве файла cookie для аутентификации. Когда вы читаете статьи, сравнивающие их, они обычно говорят об использовании JWT, отправляемого в качестве маркера-носителя с помощью кода переднего плана, против файла cookie аутентификации, который соответствует некоторому кэшированному сеансу или пользовательским данным на внутреннем конце.
  2. JWT предлагает множество функций и помещает их в стандарт, чтобы их можно было использовать между сторонами. JWT может выступать в качестве подписанного утверждения некоторых фактов во многих разных местах. Файл cookie, независимо от того, какие данные вы в него помещаете или подписываете его, имеет смысл использовать только между браузером и конкретным бэкэндом. JWT может использоваться из браузера в бэкэнд, между бэкэндами, контролируемыми разными сторонами (например, OpenId Connect), или в бэкэнд-сервисах одной из сторон. Что касается вашего конкретного примера ваших подписанных куки-файлов, вы, вероятно, можете выполнять те же функции ("не используя идентификатор сеанса, не использовать серверную память или файловое хранилище"), что и JWT в этом случае, но вы проигрываете библиотеки и рецензируете стандарт, в дополнение к проблемам CSRF, о которых говорится в другом ответе.

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

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

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

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

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

Печенье

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

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

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

JWT

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

  1. Да, файлы cookie можно использовать для чего угодно.
  2. Зачем нам нужен JWT?

JSON - это лучший (и единственный необходимый ИМХО) формат данных, в который вы можете поместить все, что хотите.

С JWT вы не ограничены размером ваших данных, с файлами cookie у вас есть только 4093 байта на домен — для всех файлов cookie, а не для одного.

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

Другие вопросы по тегам