Проверка подлинности токена и файлы cookie

В чем разница между аутентификацией токена и аутентификацией с использованием файлов cookie?

Я пытаюсь реализовать демоверсию Ember Auth Rails, но я не понимаю причин использования аутентификации токена, как описано в FAQ по Ember Auth на вопрос «Почему аутентификация токена?»

Типичное веб-приложение по большей части не имеет состояния , поскольку оно имеет характер запроса / ответа . Протокол HTTP является лучшим примером протокола без сохранения состояния . Но поскольку большинству веб-приложений требуется состояние , чтобы удерживать это состояние между сервером и клиентом, файлы cookie используются таким образом, что сервер может отправлять каждый ответ обратно клиенту. Это означает, что следующий запрос от клиента будет включать этот файл cookie и, таким образом, будет распознаваться сервером. Таким образом , сервер может поддерживать сеанс с лицом без клиента, зная , в основном все о приложении состоянии , но хранится на сервере. В этом сценарии клиент ни разу не держитсостояние , которое не так, как работает Ember.js .

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

Однако состояние удержания в клиенте также может иногда вызывать проблемы параллелизма, которые просто отсутствуют в ситуациях без состояния. Ember.js, однако, также решает эту проблему для вас, в частности, ember-data строится с учетом этого. В заключение, Ember.js - это фреймворк, разработанный для клиентов с состоянием .

Ember.js не работает как обычное веб-приложение без сохранения состояния , в котором сеанс , состояние и соответствующие файлы cookie почти полностью обрабатываются сервером. Ember.js хранит свое состояние полностью в javascript (в памяти клиента, а не в DOM, как некоторые другие фреймворки) и не нуждается в сервере для управления сеансом. В результате Ember.js становится более универсальным во многих ситуациях, например, когда ваше приложение находится в автономном режиме.

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

По моему мнению, основная причина, по которой вместо маркеров cookie используется токен аутентификации, как указано в FAQ по Ember Auth, в первую очередь обусловлена ​​природой платформы Ember.js, а также тем, что она больше соответствует парадигме веб-приложения с отслеживанием состояния . Поэтому механизм cookie - не лучший подход при создании приложения Ember.js.

Я надеюсь, что мой ответ придаст больше значения вашему вопросу.

Http без гражданства. Чтобы авторизовать вас, вы должны «подписывать» каждый отдельный запрос, отправляемый на сервер.

Проверка подлинности токена

• Запрос к серверу подписывается «токеном» - обычно это означает установку определенных заголовков http, однако они могут быть отправлены в любой части http-запроса (тело POST и т. Д.)

• Плюсы:

  • Вы можете авторизовать только те запросы, которые хотите авторизовать. (Файлы cookie - даже файлы cookie авторизации отправляются для каждого отдельного запроса.)
  • Невосприимчивость к XSRF (Краткий пример XSRF - я отправлю вам ссылку в электронной почте, которая будет выглядеть следующим образом <img src="http://bank.com?withdraw=1000&to=myself" />, и если вы вошли в систему с помощью cookie-аутентификации на bank.com, а bank.com не имеет каких-либо средств XSRF Защита, я сниму деньги с вашего аккаунта просто потому, что ваш браузер вызовет авторизованный запрос GET для этого URL.) Обратите внимание, что вы можете предпринять меры по борьбе с подделкой, используя аутентификацию на основе файлов cookie, но вы должны ее реализовать.
  • Файлы cookie связаны с одним доменом. Файл cookie, созданный на домене foo.com, не может быть прочитан доменом bar.com, в то время как вы можете отправлять токены на любой домен, который вам нравится. Это особенно полезно для одностраничных приложений, которые используют несколько служб, требующих авторизации, поэтому у меня может быть веб-приложение на домене myapp.com, которое может отправлять авторизованные запросы на стороне клиента на myservice1.com и myservice2.com.
• Минусы:
  • Вы должны хранить токен где-нибудь; пока куки хранятся «из коробки». На ум приходят местоположения localStorage (con: токен сохраняется даже после закрытия окна браузера), sessionStorage (pro: токен удаляется после закрытия окна браузера, con: открытие ссылки в новой вкладке отобразит эту вкладку анонимный) и файлы cookie (Pro: токен удаляется после закрытия окна браузера. Если вы используете файл cookie сеанса, вы будете аутентифицированы при открытии ссылки в новой вкладке, и вы будете защищены от XSRF, так как игнорируете cookie для аутентификации, вы просто используете его в качестве хранилища токенов. Con: cookie отправляются для каждого отдельного запроса. Если этот cookie не помечен только как https, вы открыты для атакующего в середине.)
  • Несколько проще выполнить XSS-атаку против аутентификации на основе токенов (т. Е. Если я смогу запустить внедренный скрипт на вашем сайте, я могу украсть ваш токен, однако аутентификация на основе файлов cookie также не является «серебряной пулей»), в то время как файлы cookie, помеченные как Клиент не может прочитать только http, клиент может отправлять запросы от вашего имени, которые автоматически включают файл авторизации.)
  • Запросы на загрузку файла, которые должны работать только для авторизованных пользователей, требуют использования File API. Тот же запрос работает из коробки для проверки подлинности на основе файлов cookie.

Проверка подлинности cookie

• Запрос к серверу всегда выполняется авторизационным cookie.
• Плюсы:
  • Файлы cookie могут быть помечены как «только для http», что делает невозможным их чтение на стороне клиента. Это лучше для защиты от XSS-атак.
  • Выходит из коробки - вам не нужно реализовывать какой-либо код на стороне клиента.
• Минусы:
  • Связано с одним доменом. (Таким образом, если у вас есть одностраничное приложение, которое отправляет запросы нескольким службам, вы можете закончить сумасшедшими вещами, такими как обратный прокси-сервер.)
  • Уязвим к XSRF. Вы должны принять дополнительные меры для защиты своего сайта от подделки межсайтовых запросов.
  • Отправляются для каждого отдельного запроса (даже для запросов, которые не требуют аутентификации).

В целом, я бы сказал, что токены дают вам большую гибкость (поскольку вы не привязаны к одному домену). Недостатком является то, что вы должны делать довольно много кодирования самостоятельно.

• Токены нужно где-то хранить (локальное / сессионное хранилище или куки)

• Токены могут истекать как куки, но у вас есть больше контроля

• Локальное / сессионное хранилище не будет работать между доменами, используйте маркер cookie

• Предварительные запросы будут отправляться на каждый запрос CORS

• Когда вам нужно что-то передать, используйте токен, чтобы получить подписанный запрос

• С XSS легче иметь дело, чем с XSRF

• Токен отправляется на каждый запрос, следите за его размером

• Если вы храните конфиденциальную информацию, зашифруйте токен

• Веб-токены JSON можно использовать в OAuth

• Токены не являются серебряными пулями, тщательно продумайте варианты использования авторизации

http://blog.auth0.com/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/

http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/

Для гуглеров :

• НЕ смешивайте состояние с механизмами передачи состояния

STATEFULNESS

• Stateful = сохранить информацию об авторизации на стороне сервера, это традиционный способ
• Stateless = сохранить информацию авторизации на стороне клиента вместе с подписью для обеспечения целостности

МЕХАНИЗМЫ

• Cookie = специальный заголовок со специальной обработкой (доступ, хранение, срок действия, безопасность, автоматическая передача) браузерами
• Пользовательские заголовки = например Authorization, просто заголовки без какой-либо специальной обработки, клиент должен управлять всеми аспектами передачи
• Другое . Могут быть использованы другие механизмы передачи, например, строка запроса была выбрана для передачи идентификатора авторизации на некоторое время, но была заброшена из-за своей незащищенности

СРАВНЕНИЕ СОСТОЯНИЯ

• «Stateful авторизация» означает, что сервер хранит и поддерживает информацию авторизации пользователя на сервере, делая авторизацию частью состояния приложения.
• Это означает, что клиенту нужно только сохранять «идентификатор авторизации», а сервер может считывать детали аутентификации из своей базы данных.
• Это означает, что сервер хранит пул активных авторизаций (пользователей, которые вошли в систему) и будет запрашивать эту информацию для каждого запроса.
• «Авторизация без сохранения состояния» означает, что сервер не хранит и не поддерживает информацию об аутентификации пользователя, он просто не знает, какие пользователи выполнили вход, и полагается на клиента для получения информации об аутентификации.
• Клиент будет хранить полную информацию об аутентификации, например, кто вы (идентификатор пользователя), и, возможно, права доступа, срок действия и т. Д., Это больше, чем просто идентификатор аутентификации, поэтому ему присваивается новый токен имени
• Очевидно, что клиенту нельзя доверять, поэтому данные аутентификации хранятся вместе с подписью, с hash(data + secret key)которой секретный ключ известен только серверу, поэтому можно проверить целостность данных токена.
• Обратите внимание, что маркерный механизм просто обеспечивает целостность, но не конфиденциальность, клиент должен реализовать это
• Это также означает, что для каждого запроса клиент должен предоставить полный токен, который требует дополнительной пропускной способности.

МЕХАНИЗМ СРАВНЕНИЯ

• «Cookie» - это просто заголовок, но с некоторыми предварительно загруженными операциями в браузерах
• Cookie может быть установлен сервером и автоматически сохранен клиентом, и автоматически отправит для того же домена
• Cookie может быть помечен как httpOnlyпредотвращающий доступ клиента к JavaScript
• Предварительно загруженные операции могут быть недоступны на платформах, отличных от браузеров (например, мобильных), что может привести к дополнительным усилиям
• «Пользовательские заголовки» - это просто пользовательские заголовки без предварительно загруженных операций.
• Клиент несет ответственность за получение, хранение, защиту, отправку и обновление пользовательского раздела заголовка для каждого запроса, это может помочь предотвратить простое встраивание вредоносного URL

SUM-UP

• В этом нет никакой магии, состояние аутентификации должно храниться где-то на сервере или клиенте.
• Вы можете внедрить Stateful / Stateless с помощью куки или других пользовательских заголовков
• Когда люди говорят об этих вещах, их мышление по умолчанию в основном таково: без сохранения состояния = токен + настраиваемый заголовок, с сохранением состояния = идентификатор авторизации + cookie; это не единственно возможные варианты
• У них есть свои плюсы и минусы, но даже для зашифрованных токенов не стоит хранить конфиденциальную информацию

Ссылка на сайт

Я считаю, что здесь есть некоторая путаница. Существенная разница между проверкой подлинности на основе файлов cookie и тем, что теперь возможно в HTML5 Web Storage, заключается в том, что браузеры созданы для отправки данных cookie, когда они запрашивают ресурсы из домена, который их устанавливает. Вы не можете предотвратить это, не отключив куки. Браузеры не отправляют данные из веб-хранилища, если их не отправляет код на странице . И страницы могут получать доступ только к тем данным, которые они хранят, а не к данным, сохраненным другими страницами.

Таким образом, пользователь беспокоится о том, как его данные cookie могут использоваться Google или Facebook, чтобы отключить файлы cookie. Но у них меньше причин отключать веб-хранилище (пока рекламодатели не найдут способ использовать это).

Таким образом, в этом разница между файлами cookie и токенами, последний использует Web Storage.

Аутентификация на основе токенов не имеет состояния, серверу не нужно хранить пользовательскую информацию в сеансе. Это дает возможность масштабировать приложение, не беспокоясь о том, где пользователь выполнил вход. Существует веб-инфраструктура Server Framework для файлов cookie, в то время как для маркеров это не является проблемой. Таким образом, один и тот же токен может быть использован для извлечения защищенного ресурса из домена, отличного от того, в который мы вошли, что позволяет избежать другой аутентификации uid / pwd.

Очень хорошая статья здесь:

http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs

Используйте токен, когда ...

Федерация желательна. Например, вы хотите использовать одного поставщика (Token Dispensor) в качестве эмитента токена, а затем использовать свой сервер API в качестве средства проверки токена. Приложение может пройти аутентификацию в Token Dispensor, получить токен, а затем представить этот токен вашему серверу API для проверки. (То же самое работает с Google Sign-In. Или Paypal. Или Salesforce.com. И т. Д.)

Требуется асинхронность. Например, вы хотите, чтобы клиент отправил запрос, а затем где-то сохранил этот запрос, чтобы его позже обработала отдельная система. Эта отдельная система не будет иметь синхронного соединения с клиентом и может не иметь прямого соединения с центральным токен диспансером. JWT может считываться системой асинхронной обработки, чтобы определить, можно ли и нужно ли выполнить рабочий элемент в это более позднее время. Это, в некотором роде, связано с идеей Федерации выше. Но будьте осторожны: истекает срок действия JWT. Если очередь, содержащая рабочий элемент, не обрабатывается в течение времени жизни JWT, то заявки больше не следует доверять.

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

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

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

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

Это позволяет использовать единый сценарий, который снижает общее трение в пользовательском интерфейсе. Теоретически, Интернет также становится более безопасным, так как появляются специализированные поставщики удостоверений, которые предоставляют услуги аутентификации, вместо того, чтобы каждый веб-сайт ma-pa раскручивал свои собственные, вероятно, наполовину испеченные, системы аутентификации. По мере появления этих провайдеров стоимость предоставления защищенных веб-ресурсов даже для самых базовых ресурсов стремится к нулю.

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