RESTful-аутентификация как форма состояния - PullRequest
4 голосов
/ 31 марта 2011

Его невозможно иметь аутентификацию без состояния.Итак, при разработке программного обеспечения RESTful с аутентификацией мы ставим под угрозу эту архитектуру ради безопасности?Как далеко это может зайти?Можете ли вы хранить любое количество состояний до тех пор, пока оно находится в процессе создания более безопасной системы?

Передача состояния представления или REST имеет ряд основных концепций проектирования.Одним из наиболее важных является то, что REST должен быть без состояния или, если цитировать Википейду:

"... Клиент в состоянии покоя может взаимодействовать со своим пользователем, ноне создает нагрузки, и не использует хранилище для каждого клиента на серверах или в сети. "

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

Ответы [ 4 ]

8 голосов
/ 31 марта 2011

RESTful-системы имеют два типа состояния.Состояние клиентского приложения и состояние ресурса.Важным моментом в состоянии ресурса является то, что он должен иметь идентификатор, например, URL.

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

Состояние сеанса сервера портит ситуацию, поскольку люди используют его, изменяя содержимое ответав зависимости от того, кто запрашивает ресурс.Это усложняет создание закладок, затрудняет совместное использование URL-адресов, затрудняет кэширование.

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

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

1 голос
/ 30 сентября 2014

Старый вопрос, но я считаю, что REST фактически требует, чтобы сервер не имел состояния, в том смысле, что на сервере не хранятся данные о сеансе.

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

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

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

Сервер теперь может эффективно и надежно аутентифицировать вас при каждом запросе. На стороне сервера нет состояния сеанса - запрос содержит всю необходимую информацию.

1 голос
/ 31 марта 2011

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

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

См. Эту статью для примера на C # с WCF.

0 голосов
/ 31 марта 2011

Вкратце: безгражданство REST утверждает, что состояние остается за клиентом;)

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

Состояние сеанса сохраняется на клиенте.«Хак», который используется в терминах аутентификации в REST, заключается в том, что информация, относящаяся к сеансу (состояние), может быть захвачена как ресурс, который может быть сопоставлен с сеансом клиента.Например, время начала, сертификаты, идентификаторы сеанса с соответствующей информацией и т. Д.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...