В чем разница между аутентификацией маркера и аутентификацией с помощью файлов cookie?
Я пытаюсь реализовать Ember Auth Rails Demo, но я не понимаю причин использования аутентификации токенов, как описано в Ember Auth FAQ на вопрос "Почему аутентификация с помощью токена?"
Типичное веб-приложение по большей части не имеет состояния, из-за природы запроса/ответа. Протокол 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 и т.д.)
Плюсы:
<img src="http://bank.com?withdraw=1000&to=myself"/>, и если вы вошли в систему посредством аутентификации с использованием cookie файлов для bank.com, и bank.com не имеет никаких средств защиты XSRF, я сниму деньги с вашего счета просто потому, что ваш браузер вызовет авторизованный запрос GET на этот URL-адрес.) Примечание Есть меры против подделки, которые вы можете сделать с помощью аутентификации на основе файлов cookie, но вы должны реализовать их.Проверка подлинности cookie
В целом, я бы сказал, что токены дают вам большую гибкость (поскольку вы не привязаны к одному домену). Недостатком является то, что вы должны делать довольно много кодирования самостоятельно.
Токены должны храниться где-нибудь (локальное/сеансовое хранилище или файлы cookie)
Токены могут заканчиваться как файлы cookie, но у вас больше контроля
Локальное/сеансовое хранилище не будет работать в разных доменах, используйте cookie-маркер
Запросы предварительной проверки будут отправляться по каждому запросу CORS
Когда вам нужно что-то передать, используйте токен, чтобы получить подписанный запрос
С XSS легче справляться с XSSF
Токен отправляется по каждому запросу, следить за его размером
Если вы храните конфиденциальную информацию, зашифруйте токен
В OAuth могут использоваться тестеры JSON Web
Токены - это не серебряные пули, тщательно подумайте о ваших случаях использования авторизации
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/
Я считаю, что здесь есть некоторая путаница. Существенным различием между аутентификацией на основе файлов cookie и тем, что теперь возможно с HTML5 Web Storage является то, что браузеры созданы для отправки данных cookie всякий раз, когда они запрашивают ресурсы из домена, который их установил, Вы не можете предотвратить это, не отключая куки. Браузеры не отправляют данные из Web Storage, если только код на странице не отправляет его. И страницы могут получать только данные, которые они хранят, а не данные, хранящиеся на других страницах.
Таким образом, пользователь обеспокоен тем, как их файлы cookie могут использоваться Google или Facebook, могут отключить файлы cookie. Но у них меньше оснований отключать веб-хранилище (пока рекламодатели не найдут способ использовать это).
Итак, что разница между основанием на основе файлов cookie и токена, последний использует Web Storage.
Аутентификация на основе токена не поддерживается, сервер не должен хранить информацию о пользователе в сеансе. Это дает возможность масштабировать приложение, не беспокоясь о том, где пользователь вошел в систему. Сходство веб-сервера с базой данных основано на том, что это не проблема с маркером. Таким образом, один и тот же токен может использоваться для извлечения защищенного ресурса из домена, отличного от того, с которым мы вошли в систему, который позволяет избежать другой аутентификации uid/pwd.
Очень хорошая статья здесь:
Одно из основных отличий заключается в том, что на cookie файлы распространяется та же политика происхождения, а на токены - нет. Это создает все виды эффектов нисходящего потока.
Поскольку файлы cookie отправляются только определенному хосту и от него, этот хост должен нести бремя аутентификации пользователя, и пользователь должен создать учетную запись с данными безопасности на этом хосте, чтобы их можно было проверить.
Токены, с другой стороны, выпускаются и не подпадают под ту же политику происхождения. Эмитентом может быть буквально любой, и хост сам решает, каким эмитентам доверять. Эмитент, такой как Google и Facebook, обычно пользуется большим доверием, поэтому хост может перенести бремя аутентификации пользователя (включая сохранение всех данных безопасности пользователя) на другую сторону, и пользователь может объединить свои личные данные под конкретным эмитентом и не должен помнить куча разных паролей для каждого хоста, с которым они взаимодействуют.
Это позволяет использовать единый сценарий, который снижает общее трение в пользовательском интерфейсе. Теоретически, Интернет также становится более безопасным, так как появляются специализированные поставщики идентификационных данных, которые предоставляют услуги аутентификации, вместо того, чтобы каждый веб-сайт ma-pa раскручивал свои собственные, вероятно, наполовину испеченные, системы аутентификации. И по мере появления этих провайдеров стоимость предоставления защищенных веб-ресурсов даже для самых базовых ресурсов стремится к нулю.
Таким образом, в целом токены уменьшают трения и затраты, связанные с обеспечением аутентификации, и переносят бремя различных аспектов защищенной сети на централизованные стороны, которые могут лучше внедрять и поддерживать системы безопасности.
Используйте токен, когда...
Федерация желательна. Например, вы хотите использовать одного поставщика (Token Dispensor) в качестве эмитента токена, а затем использовать свой сервер API в качестве средства проверки токена. Приложение может пройти аутентификацию в Token Dispensor, получить токен, а затем представить этот токен вашему серверу API для проверки. (То же самое работает с Google Sign-In. Или Paypal. Или Salesforce.com. И т.д.)
Требуется асинхронность. Например, вы хотите, чтобы клиент отправил запрос, а затем где-то сохранил этот запрос, чтобы его позже обработала отдельная система. Эта отдельная система не будет иметь синхронного соединения с клиентом и может не иметь прямого соединения с центральным токен диспансером. JWT может считываться системой асинхронной обработки, чтобы определить, можно ли и нужно ли выполнить рабочий элемент в это более позднее время. Это в некотором роде связано с идеей Федерации выше. Но будьте осторожны: истекает срок действия JWT. Если очередь, содержащая рабочий элемент, не обрабатывается в течение времени жизни JWT, то заявки больше не следует доверять.
Cient Подписанный запрос не требуется. Здесь запрос подписывается клиентом с использованием его закрытого ключа, а сервер проверяет его, используя уже зарегистрированный открытый ключ клиента.