wrong - Аутентификация RESTful




validation error response (10)

Что означает RESTful Authentication и как оно работает? Я не могу найти хороший обзор в Google. Мое единственное понимание заключается в том, что вы передаете ключ сеанса (remeberal) в URL-адрес, но это может быть ужасно неправильно.


В «очень проницательной» статье, упомянутой @skrebel ( here ), обсуждается запутанный, но действительно сломанный метод аутентификации.

Вы можете попробовать посетить страницу (которая должна быть доступна только для аутентифицированного пользователя) http://www.berenddeboer.net/rest/site/authenticated.html без каких-либо учетных данных.

(Извините, я не могу прокомментировать ответ.)

Я бы сказал, что REST и аутентификация просто не смешиваются. REST означает «без гражданства», но «аутентифицированный» - это состояние. Вы не можете иметь их обоих на одном уровне. Если вы защитник RESTful и нахмурились на государствах, тогда вам нужно пойти с HTTPS (т.е. оставить проблему безопасности на другом уровне).


Вот действительно и полностью RESTful решение для проверки подлинности:

  1. Создайте пару открытого / закрытого ключей на сервере аутентификации.
  2. Распределите открытый ключ на всех серверах.
  3. Когда клиент аутентифицируется:

    3.1. выдать токен, который содержит следующее:

    • Время истечения
    • имя пользователя (необязательно)
    • пользователи IP (необязательно)
    • хэш пароля (необязательно)

    3.2. Зашифруйте токен с помощью закрытого ключа.

    3.3. Отправлять зашифрованный токен пользователю.

  4. Когда пользователь обращается к любому API, он также должен передать свой токен аутентификации.

  5. Серверы могут проверить, что токен действителен, дешифруя его с помощью открытого ключа сервера auth.

Это аутентификация без аутентификации / RESTful.

Обратите внимание, что если бы хэш-код пароля был включен, пользователь также отправил незашифрованный пароль вместе с токеном аутентификации. Сервер может проверить, соответствует ли пароль паролю, который использовался для создания токена аутентификации, путем сравнения хэшей. Для этого потребуется безопасное соединение с использованием HTTPS. Javascript на стороне клиента может обрабатывать пароль пользователя и сохранять его на стороне клиента, либо в памяти, либо в cookie, возможно, зашифрованном с помощью открытого ключа сервера.


Прежде всего, веб-служба RESTful является БЕЗОПАСНОЙ (или, другими словами, БЕСПЛАТНО ). Таким образом, служба RESTful не имеет и не должна иметь понятия сеанса или файлов cookie. Способ аутентификации или авторизации в службе RESTful - это использование заголовка HTTP-авторизации, как определено в спецификациях HTTP RFC 2616. Каждый отдельный запрос должен содержать заголовок HTTP-авторизации, и запрос должен быть отправлен по HTTP-соединению (SSL). Это правильный способ сделать аутентификацию и проверить авторизацию запросов в веб-службах HTTP RESTful. Я реализовал веб-службу RESTful для приложения Cisco PRIME Performance Manager в Cisco Systems. И как часть этой веб-службы, я также реализовал аутентификацию / авторизацию.

Рубенс Гомес.


Хватит уже сказано на эту тему хорошими людьми здесь. Но вот мои 2 цента.

Существует два режима взаимодействия:

  1. от человека к машине (HTM)
  2. машина-машина (MTM)

Машина является общим знаменателем, выраженным как API REST, а субъекты / клиенты - это люди или машины.

Теперь, в архитектуре RESTful, концепция безгражданства подразумевает, что все соответствующие состояния приложения (то есть состояния клиентской стороны) должны предоставляться с каждым запросом. Под релевантным подразумевается то, что требуется REST API для обработки запроса и предоставления соответствующего ответа.

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

Рассмотрим это: у вас есть информационная платформа, открытая для активов API REST. Возможно, у вас есть платформа BI для самообслуживания, которая обрабатывает все кубы данных. Но вы хотите, чтобы ваши (человеческие) клиенты получили доступ к этому через (1) веб-приложение, (2) мобильное приложение и (3) какое-то стороннее приложение. В конце концов, даже цепочка MTM ведет к HTM - правильно. Таким образом, человеческие пользователи остаются на вершине информационной цепочки.

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

Понятие аутентификации применяется по всем направлениям. Как вы это разработаете, чтобы ваши API-интерфейсы REST были доступны в едином, защищенном виде? Как я вижу это, есть два способа:

Путь-1:

  1. Для начала нет входа. Каждый запрос выполняет вход в систему
  2. Клиент отправляет свои идентификационные параметры + параметры запроса с каждым запросом
  3. REST API берет их, поворачивает, пингует пользовательское хранилище (что бы это ни было) и подтверждает auth
  4. Если auth установлен, обслуживает запрос; в противном случае отказывается с соответствующим кодом статуса HTTP
  5. Повторите вышеуказанное для каждого запроса по всем API-интерфейсам REST в вашем каталоге

Путь-2:

  1. Клиент начинается с запроса auth
  2. API REST входа в систему будет обрабатывать все такие запросы
  3. Он принимает параметры auth (ключ API, uid / pwd или все, что вы выбираете) и проверяет auth на хранилище пользователей (LDAP, AD или MySQL DB и т. Д.),
  4. Если проверено, создается токен аутентификации и передает его клиенту / вызывающему абоненту
  5. Затем вызывающий абонент отправляет этот токен аутентификации + запрашивает определенные параметры с каждым последующим запросом к другим API-интерфейсам REST для бизнеса, до выхода из системы или до истечения срока аренды

Очевидно, что в Way-2 API REST будет нужен способ распознавания и доверия к токену как действительный. API-интерфейс Login API выполнил проверку подлинности, поэтому для того, чтобы «ключ-ключ» был доверен другим API-интерфейсам REST в вашем каталоге.

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

Но я отвлекся.

Дело в том, что «состояние» (об аутентифицированном статусе клиента) необходимо поддерживать и совместно использовать, чтобы все API REST могли создать круг доверия. Если мы этого не сделаем, это путь-1, мы должны признать, что акт аутентификации должен выполняться для любых / всех входящих запросов.

Выполнение проверки подлинности - это ресурсоемкий процесс. Представьте, что вы выполняете SQL-запросы для каждого входящего запроса в своем хранилище пользователей, чтобы проверить соответствие uid / pwd. Или для шифрования и выполнения хеш-совпадений (стиль AWS). И в архитектуре каждый API REST должен будет выполнить это, я подозреваю, используя общую службу входа в систему. Потому что, если вы этого не сделаете, вы повредите код auth везде. Большой беспорядок.

Так что больше слоев, больше латентности.

Теперь возьмите Way-1 и применитесь к HTM. Ваш пользователь (человек) действительно заботится, если вам нужно отправить uid / pwd / hash или что угодно с каждым запросом? Нет, если вы не беспокоите ее, бросая страницу auth / login каждую секунду. Удачи, если у вас есть клиенты. Итак, что вы будете делать, это хранить информацию для входа где-то на стороне клиента, в браузере, в самом начале и отправлять ее с каждым сделанным запросом. Для пользователя (пользователя) она уже вошла в систему и доступна «сессия». Но на самом деле она аутентифицируется по каждому запросу.

То же самое с Way-2. Ваш (пользователь) пользователь никогда не заметит. Поэтому никакого вреда не было.

Что делать, если мы применим Way-1 к MTM? В этом случае, поскольку его машина, мы можем избавиться от этого парня, попросив его предоставить информацию аутентификации с каждым запросом. Никто не заботится! Выполнение Way-2 на MTM не вызовет никакой особой реакции; его проклятая машина. Это могло бы заботиться меньше!

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

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


Это, конечно, не о «сеансовых ключах», поскольку обычно используется для ссылки на сеансовую аутентификацию, которая выполняется во всех ограничениях REST. Каждый запрос является самоописательным и содержит достаточную информацию для авторизации запроса самостоятельно без какого-либо состояния приложения на стороне сервера.

Самый простой способ приблизиться к этому - начать с встроенных механизмов аутентификации HTTP в RFC 2617 .


Я сомневаюсь, что люди с энтузиазмом кричали «HTTP-аутентификация», когда-либо пробовали сделать приложение на основе браузера (вместо веб-сервиса от машины к машине) с помощью REST (без обид - я просто не думаю, что они когда-либо сталкивались с осложнениями) ,

Проблемы, которые я обнаружил при использовании HTTP-аутентификации в службах RESTful, которые создают HTML-страницы для просмотра в браузере, следующие:

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

Очень проницательная статья, которая решает эти вопросы по пунктам, here , но это приводит к большому браузеру javascript-хакерам, обходным методам обходных путей и т. Д. Таким образом, он также не является совместимым с передовым способом, поэтому требуется постоянное обслуживание при выпуске новых браузеров. Я не считаю это чистым и понятным дизайном, плюс я чувствую, что для меня много лишней работы и головной боли, чтобы я мог с энтузиазмом показать свой значок REST моим друзьям.

Я считаю, что cookie - это решение. Но подождите, печенье злые, не так ли? Нет, они не такие, как часто используются куки, это зло. Сам файл cookie - это всего лишь часть клиентской информации, точно так же, как информация об аутентификации HTTP, которую браузер будет отслеживать во время просмотра. И эта часть клиентской информации отправляется на сервер по каждому запросу, опять же, как и HTTP-аутентификация. Понятно, что единственное отличие состоит в том, что содержимое этой части клиентского состояния может быть определено сервером как часть его ответа.

Создавая сеансы ресурса RESTful, используя только следующие правила:

  • Сеанс отображает ключ к идентификатору пользователя (и, возможно, метку времени последнего действия для тайм-аутов)
  • Если сеанс существует, это означает, что ключ действителен.
  • Вход означает POSTing to / sessions, новый ключ устанавливается как файл cookie
  • Выход из системы означает DELETEing / sessions / {key} (с перегруженным POST, помните, что мы браузер, а HTML 5 - еще длинный путь)
  • Аутентификация выполняется путем отправки ключа в виде файла cookie при каждом запросе и проверки наличия и действительности сеанса

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

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

Я считаю, что это достаточное решение, которое прекрасно работает, но я должен признать, что мне недостаточно эксперта по безопасности для выявления потенциальных явлений в этой схеме - все, что я знаю, это то, что сотни веб-приложений, не относящихся к RESTful, используют по существу то же самое протокол входа в систему ($ _SESSION в PHP, HttpSession в Java EE и т. д.). Содержимое заголовка файла cookie просто используется для адресации ресурса на стороне сервера, так же как язык приема может использоваться для доступа к ресурсам перевода и т. Д. Я чувствую, что это то же самое, но, может быть, другие нет? Что вы думаете, ребята?


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

См. http://en.wikipedia.org/wiki/Public_key_infrastructure . Если вы соблюдаете надлежащие стандарты PKI, человек или агент, который неправильно использует украденный ключ, могут быть идентифицированы и заблокированы. Если агент должен использовать сертификат, привязка становится довольно жесткой. Умный и быстродвижущийся вор может убежать, но они оставляют больше крошек.


Чтобы ответить на этот вопрос из моего понимания ...

Система проверки подлинности, использующая REST, чтобы вам не нужно было отслеживать или управлять пользователями в вашей системе. Это делается с использованием методов HTTP POST, GET, PUT, DELETE. Мы используем эти 4 метода и рассматриваем их в терминах взаимодействия с базами данных как CREATE, READ, UPDATE, DELETE (но в Интернете мы используем POST и GET, потому что в настоящее время поддерживаются теги привязки). Поэтому, рассматривая POST и GET как наш CREATE / READ / UPDATE / DELETE (CRUD), мы можем разработать маршруты в нашем веб-приложении, которые смогут определить, какое действие CRUD мы добиваемся.

Например, в приложении Ruby on Rails мы можем создать наше веб-приложение таким образом, чтобы, если пользователь, который вошел в систему, посещает http://store.com/account/logout то GET этой страницы можно просмотреть как пользователь, пытающийся выйти из системы , В нашем контроллере rails мы создадим действие в том, что регистрирует пользователя и отправляет его обратно на домашнюю страницу.

GET на странице входа даст форму. POST на странице входа будет рассматриваться как попытка входа в систему и взять данные POST и использовать его для входа в систему.

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

Я все еще участвую - если вы найдете что-то, что я сказал неправильно, пожалуйста, поправьте меня, и если вы узнаете больше о нем, вернитесь сюда. Благодарю.



Я думаю, что спокойная аутентификация включает в себя передачу токена аутентификации в качестве параметра в запросе. Примерами являются использование apikeys api's. Я не считаю, что использование файлов cookie или http auth квалифицируется.





rest-security