JWT против файлов cookie для проверки подлинности на токенах

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

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

Ответ 1

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

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

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

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

Если вы все еще заходите на этот веб-сайт при посещении вредоносного веб-сайта, который загружает страницу в вашем браузере, которая запускает POST на этот адрес, ваш браузер будет точно прикреплять файлы cookie аутентификации, позволяя злоумышленнику сменить пароль.

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

Кроме того, файлы cookie затрудняют использование приложений, отличных от браузера (например, приложений для мобильных приложений) для использования вашего API.

Ответ 2

обзор

То, о чем вы просите, - это разница между куки файлами и токенами-носителями для отправки JSON-Web-токенов (JWT) с клиента на сервер.

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

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

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

печенье

Файл 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, чтобы узнать больше.

Ответ 3

В дополнение к тому, что MvdD сообщил о том, что файлы cookie автоматически отправляются:

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

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

Ответ 4

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

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

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