Этот вопрос был рассмотрен, в несколько иной форме, подробно, здесь:
RESTful аутентификация
Но это обращается к нему со стороны сервера. Давайте посмотрим на это со стороны клиента. Прежде чем мы сделаем это, есть важная прелюдия:
Javascript Crypto безнадежен
Статья Матасано об этом известна, но содержащиеся в ней уроки довольно важны:
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
Подвести итоги:
- Атака «человек посередине» может тривиально заменить ваш криптографический код
<script>
function hash_algorithm(password){ lol_nope_send_it_to_me_instead(password); }</script>
- Атака «человек посередине» тривиальна в отношении страницы, которая обслуживает любой ресурс через соединение без SSL.
- Если у вас есть SSL, вы все равно используете настоящее крипто.
И добавить собственное следствие:
- Успешная атака XSS может привести к тому, что злоумышленник выполнит код в браузере вашего клиента, даже если вы используете SSL - так что даже если у вас разбит каждый хэтч, криптография вашего браузера все равно может дать сбой, если злоумышленник найдет способ выполнить любой код JavaScript в чужом браузере.
Это делает многие схемы аутентификации RESTful невозможными или глупыми, если вы собираетесь использовать клиент JavaScript. Давайте смотреть!
HTTP Basic Auth
Прежде всего, HTTP Basic Auth. Самая простая схема: просто передайте имя и пароль при каждом запросе.
Конечно, для этого абсолютно необходим SSL, потому что вы передаете кодированное Base64 (обратимо) имя и пароль при каждом запросе. Любой, кто слушает линию, может легко извлечь имя пользователя и пароль. Большинство аргументов «Базовая аутентификация небезопасна» происходят из места «Базовая аутентификация через HTTP», что является ужасной идеей.
Браузер обеспечивает встроенную поддержку HTTP Basic Auth, но это ужасно, и вам, вероятно, не стоит использовать его для своего приложения. Однако альтернативой является сохранение имени пользователя и пароля в JavaScript.
Это самое ОТЛИЧНОЕ решение. Сервер не требует никакого знания состояния и проверяет подлинность каждого отдельного взаимодействия с пользователем. Некоторые энтузиасты REST (в основном, соломенные) настаивают на том, что поддержание любого рода состояния является ересью и пойдет на поводу, если вы подумаете о каком-либо другом методе аутентификации. У такого соответствия стандартам есть теоретические преимущества - он поддерживается Apache «из коробки» - вы можете хранить свои объекты в виде файлов в папках, защищенных файлами .htaccess, если хотите.
Проблема ? Вы кэшируете на стороне клиента имя пользователя и пароль. Это дает злому злу лучший выход из ситуации - даже самые элементарные уязвимости XSS могут привести к тому, что клиент отправит свое имя пользователя и пароль на злой сервер. Вы можете попытаться уменьшить этот риск, хэшируя и пересылая пароль, но помните: JavaScript Crypto безнадежен . Вы можете уменьшить этот риск, оставив его на усмотрение поддержки Basic Auth в браузере, но, как упоминалось ранее, это ужасно, как грех.
HTTP Digest Auth
Возможна ли дайджест-аутентификация с помощью jQuery?
Более «безопасная» аутентификация - это запрос хэша запроса / ответа. За исключением JavaScript, Crypto безнадежен , поэтому он работает только через SSL, и вам все равно придется кэшировать имя пользователя и пароль на стороне клиента, что делает его более сложным, чем HTTP Basic Auth, но не более безопасным .
Проверка подлинности запроса с дополнительными параметрами подписи.
Еще одна более «безопасная» аутентификация, где вы шифруете свои параметры одноразовыми и временными данными (для защиты от повторных и временных атак) и отправляете. Одним из лучших примеров этого является протокол OAuth 1.0, который, насколько я знаю, довольно ошеломляющий способ реализации аутентификации на REST-сервере.
http://tools.ietf.org/html/rfc5849
О, но нет никаких клиентов OAuth 1.0 для JavaScript. Зачем?
JavaScript Crypto безнадежен , помните. JavaScript не может участвовать в OAuth 1.0 без SSL, и вам все равно нужно хранить имя пользователя и пароль клиента локально - что относит их к той же категории, что и Digest Auth - это сложнее, чем HTTP Basic Auth, но не более безопасно .
знак
Пользователь отправляет имя пользователя и пароль, а взамен получает токен, который можно использовать для аутентификации запросов.
Это немного более безопасно, чем HTTP Basic Auth, потому что, как только транзакция с именем пользователя / паролем будет завершена, вы можете отбросить конфиденциальные данные. Он также менее RESTful, поскольку токены составляют «состояние» и усложняют реализацию сервера.
SSL Still
Проблема, однако, в том, что вам все еще нужно отправить это начальное имя пользователя и пароль, чтобы получить токен. Конфиденциальная информация по-прежнему касается вашего компромиссного JavaScript.
Чтобы защитить учетные данные вашего пользователя, вам все равно нужно держать злоумышленников вне вашего JavaScript, и вам все равно нужно отправить имя пользователя и пароль по сети. Требуется SSL.
Срок действия токена
Распространено применение политик токенов, например «эй, когда этот токен был слишком долгим, откажитесь от него и заставьте пользователя снова аутентифицироваться». или «Я уверен, что единственный IP-адрес, разрешенный для использования этого токена XXX.XXX.XXX.XXX». Многие из этих политик являются довольно хорошими идеями.
Firesheeping
Однако использование токена без SSL по-прежнему уязвимо для атаки, называемой «подделка»: http://codebutler.github.io/firesheep/
Злоумышленник не получает учетные данные вашего пользователя, но он все равно может притвориться вашим пользователем, что может быть довольно плохо.
tl; dr: отправка незашифрованных токенов по проводам означает, что злоумышленники могут легко получить эти токены и выдать себя за пользователя. FireSheep - это программа, которая делает это очень просто.
Отдельная, более безопасная зона
Чем больше приложение, которое вы запускаете, тем труднее абсолютно гарантировать, что они не смогут внедрить некоторый код, который изменяет способ обработки конфиденциальных данных. Вы абсолютно доверяете своему CDN? Ваши рекламодатели? Ваша собственная кодовая база?
Общий для деталей кредитной карты и менее общий для имени пользователя и пароля - некоторые разработчики хранят «ввод конфиденциальных данных» на отдельной странице от остальной части своего приложения, страницу, которой можно жестко управлять и как можно лучше ее заблокировать, желательно такую, которая трудно фишинг пользователей.
Cookie (просто означает токен)
Можно (и часто) поместить маркер аутентификации в куки. Это не меняет никаких свойств auth с токеном, это скорее удобство. Все предыдущие аргументы все еще применяются.
Сессия (все еще означает просто токен)
Session Auth - это просто аутентификация токена, но с некоторыми отличиями, которые делают его немного другим:
- Пользователи начинают с токена без аутентификации.
- Бэкэнд поддерживает объект «состояние», связанный с токеном пользователя.
- Токен предоставляется в файле cookie.
- Среда приложения абстрагирует детали от вас.
Кроме того, на самом деле он ничем не отличается от Token Auth.
Это еще дальше от реализации RESTful - с объектами состояния вы идете все дальше и дальше по пути простого старого RPC на сервере с состоянием.
OAuth 2.0
OAuth 2.0 рассматривает проблему «Как Программное обеспечение A предоставляет Программному обеспечению B доступ к данным Пользователя X без программного обеспечения B, имеющего доступ к учетным данным пользователя X».
Реализация в значительной степени является просто стандартным способом для пользователя получить токен, а затем для стороннего сервиса перейти «да, этот пользователь и этот токен совпадают, и вы можете получить некоторые их данные от нас сейчас».
По сути, OAuth 2.0 - это просто протокол токенов. Он обладает теми же свойствами, что и другие протоколы токенов - вам все еще нужен SSL для защиты этих токенов - он просто меняет способ генерации этих токенов.
OAuth 2.0 может помочь вам двумя способами:
- Предоставление аутентификации / информации другим
- Получение аутентификации / информации от других
Но когда дело доходит до этого, вы просто ... используете токены.
Вернуться к вашему вопросу
Итак, вопрос, который вы задаете, заключается в следующем: «Должен ли я хранить свой токен в файле cookie, и чтобы автоматическое управление сеансами моей среды заботилось о деталях, или я должен хранить свой токен в Javascript и обрабатывать эти данные самостоятельно?»
И ответ таков: делай все, что делает тебя счастливым .
Суть автоматического управления сессиями в том, что за кулисами происходит много магии. Часто лучше самим контролировать эти детали.
Мне 21, так что SSL это да
Другой ответ: используйте https для всего, иначе разбойники украдут пароли и токены ваших пользователей.