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

Question

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

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

Answer 1

Типичное веб-приложение по большей части не имеет состояния, поскольку оно имеет характер запросов / ответов. Протокол 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.

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

Answer 2

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. Вы должны принять дополнительные меры для защиты своего сайта от подделки межсайтовых запросов.
  • Отправляются для каждого отдельного запроса (даже для запросов, которые не требуют аутентификации).

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

Answer 3

Для сотрудников Google:

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

ГОСУДАРСТВЕННОСТЬ

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

МЕХАНИЗМЫ

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

СРАВНЕНИЕ ГОСУДАРСТВЕННОСТИ

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

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

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

ПОДВЕДЕНИЕ

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

Ссылка

Answer 4

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

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

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

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

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

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

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

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

• JSON Web Tokens можно использовать в 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 5

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

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

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

Answer 6

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

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

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

Answer 7

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

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

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

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

Answer 8

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

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

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

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

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

Answer 9

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

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

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

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

Answer 10

Суммируя:

      JWT vs Cookie Auth

|                    | Cookie        | JWT                             |
| Stateless          | No            | Yes                             |
| Cross domain usage | No            | Yes                             |
| Mobile ready       | No            | Yes                             |
| Performance        | Low           | High (no need in request to DB) |
| Add to request     | Automatically | Manually (if not in cookie)     |