В чем разница между аутентификацией токена и аутентификацией с использованием файлов 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 и т. Д.)
Плюсы:
<img src="http://bank.com?withdraw=1000&to=myself" />
, и если вы вошли в систему с помощью cookie-аутентификации на bank.com, а bank.com не имеет каких-либо средств XSRF Защита, я сниму деньги с вашего аккаунта просто потому, что ваш браузер вызовет авторизованный запрос GET для этого URL.) Обратите внимание, что вы можете предпринять меры по борьбе с подделкой, используя аутентификацию на основе файлов cookie, но вы должны ее реализовать.Проверка подлинности cookie
В целом, я бы сказал, что токены дают вам большую гибкость (поскольку вы не привязаны к одному домену). Недостатком является то, что вы должны делать довольно много кодирования самостоятельно.
источник
Are send out for every single request
Токены также отправляются на каждый запросТокены нужно где-то хранить (локальное / сессионное хранилище или куки)
Токены могут истекать как куки, но у вас есть больше контроля
Локальное / сессионное хранилище не будет работать между доменами, используйте маркер 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
МЕХАНИЗМЫ
Authorization
, просто заголовки без какой-либо специальной обработки, клиент должен управлять всеми аспектами передачиСРАВНЕНИЕ СОСТОЯНИЯ
hash(data + secret key)
которой секретный ключ известен только серверу, поэтому можно проверить целостность данных токена.МЕХАНИЗМ СРАВНЕНИЯ
httpOnly
предотвращающий доступ клиента к JavaScriptSUM-UP
Ссылка на сайт
источник
Я считаю, что здесь есть некоторая путаница. Существенная разница между проверкой подлинности на основе файлов 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 раскручивал свои собственные, вероятно, наполовину испеченные, системы аутентификации. По мере появления этих провайдеров стоимость предоставления защищенных веб-ресурсов даже для самых базовых ресурсов стремится к нулю.
Таким образом, в целом токены уменьшают трения и затраты, связанные с предоставлением аутентификации, и переносят бремя различных аспектов защищенной сети на централизованные стороны, которые могут лучше внедрять и поддерживать системы безопасности.
источник