Аутентификация токена против файлов cookie

Question

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

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

Answer 1

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

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

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

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

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

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

Надеюсь, мой ответ даст больше смысла вашему вопросу.

Answer 2

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

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

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

Answer 3

• Лексемы должны быть где-то хранить (локальный/сеанса хранения или печенье)

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

• Локальное хранение/сессия не будет работать в разных доменах, используйте маркер печенье

• Предполетный запросы будут отправляться на каждый запрос 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/

Answer 4

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

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

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

Answer 5

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

Токен аутентификации

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

• Плюсы:

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

аутентификация Cookie

• запрос на сервер всегда подписан в авторизации печенье
• Pros:
  • Cookie может быть помечен как «http-only», что делает их невозможными для чтения на стороне клиента, t его лучше для защиты XSS-атаки
  • приходит из коробки - вы не должны выполнять любой код на стороне клиента
• Cons:
  • привязаны к одному домену (так что если у вас есть одностраничное приложение, которое обрабатывает запросы на несколько сервисов, которые вы можете в конечном итоге делать с сумасшедшими вещами, такими как обратный прокси).
  • Уязвим к XSRF, вам необходимо выполнить дополнительные меры, чтобы защитить ваш сайт от подделки запроса на использование сайта.
  • Отправлено для каждого си ngle запрос (даже для запроса, который не требует аутентификации)

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