Как реализовать вход в систему в веб-службе RESTful?

Как уже отмечал С.Лотт, здесь есть две вещи: вход в систему и аутентификация.

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

Клиент) Итак, все, что мне нужно, это токен доступа, но как получить такой RESTfully?
Сервер) Почему бы просто не создать его?
Клиент) Как получается?
Сервер) Для меня токен доступа не что иное, как ресурс. Таким образом, я создам один для вас в обмен на ваше имя пользователя и пароль.

Таким образом, сервер может предложить URL ресурса «/ accesstokens» для POST-запроса имени пользователя и пароля, чтобы вернуть ссылку на вновь созданный ресурс «/ accesstokens / {accesstoken}». В качестве альтернативы вы возвращаете документ, содержащий токен доступа и href со ссылкой на ресурс:

<access-token
  id="{access token id goes here; e.g. GUID}"
  href="/accesstokens/{id}"
/>

Скорее всего, вы на самом деле не создаете токен доступа в качестве подресурса и, следовательно, не будете включать его href в ответ.
Однако, если вы это сделаете, клиент может сгенерировать ссылку от своего имени или нет ? Нет!
Помните, что по-настоящему веб-службы RESTful связывают ресурсы вместе таким образом, чтобы клиент мог перемещаться самостоятельно без необходимости создания каких-либо ссылок на ресурсы.

Последний вопрос, который, вероятно, у вас возникнет, заключается в том, следует ли вам ПУСАТЬ имя пользователя и пароль в виде HTML-формы или документа, например XML или JSON - смотря как ... :-)

Вы не «входите в систему». Вы «аутентифицируете». Мир отличий.

У вас есть множество альтернатив аутентификации.

HTTP Basic, Digest, аутентификация NTLM и AWS S3

• Базовая и дайджест-аутентификация HTTP. Здесь используется заголовок HTTP_AUTHORIZATION. Это очень красиво, очень просто. Но может привести к большому трафику.

• Имя пользователя / Подпись аутентификации. Иногда это называется аутентификацией «ID и KEY». Это может использовать строку запроса.

  ?username=this&signature=some-big-hex-digest

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

• Какая-то аутентификация на основе файлов cookie. Например, OpenAM можно настроить в качестве агента для аутентификации и предоставления файла cookie, который затем может использовать ваш веб-сервер RESTful. Клиент сначала аутентифицируется, а затем предоставляет cookie с каждым запросом RESTful.

Отличный вопрос, хорошо поставленный. Мне очень нравится ответ Патрика. Я использую что-то вроде

- / users / {username} / loginsession

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

Ресурс представляет собой сеанс входа в систему и может иметь токен доступа или код авторизации, срок действия и т. Д.

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

Изменить

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

Другое решение - передать токен, OAuth или JWT или иначе, что означает, что «вход в систему» ​​уже произошел другим процессом, возможно, обычным пользовательским интерфейсом входа в систему в браузере, который основан на форме POST.

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

Он также позволяет другим службам «входить в систему» ​​и получать токен с истекающим сроком действия вместо использования предварительно выданного ключа, а также тестовых сценариев в CLI или Postman.

Поскольку с 2011 года многое изменилось ...

Если вы готовы использовать сторонний инструмент и немного отклоняетесь от REST для веб-интерфейса, рассмотрите возможность использования http://shiro.apache.org.

Широ в основном предоставляет вам фильтр сервлетов, предназначенный как для аутентификации, так и для авторизации. Вы можете использовать все методы входа в систему, перечисленные @ S.Lott, включая простую аутентификацию на основе форм.

Отфильтруйте остальные URL-адреса, требующие аутентификации, а Широ сделает все остальное.

В настоящее время я использую это в своем собственном проекте, и до сих пор он работал у меня очень хорошо.

Вот еще кое-что, что может заинтересовать людей. https://github.com/PE-INTERNATIONAL/shiro-jersey#readme

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

Что касается вашего первого вопроса, вы можете разработать Restfull API. Учетные данные (имя пользователя и пароль) будут переданы на ваш уровень сервиса. Уровень сервиса затем проверяет эти учетные данные и предоставляет токен. Учетные данные могут быть либо простым именем пользователя / паролем, либо сертификатами SSL. Сертификаты SSL используют протокол OAUTH и более безопасны.

Вы можете создать свой URI следующим образом: URI для запроса токена-> http: // myservice / some-directory / token ? (Вы можете передать Credentilals в этом URI для токена)

Вы также можете перейти по этим ссылкам для получения дополнительной информации: http://www.codeproject.com/Articles/687647/Detailed-Tutorial-for-Building-ASP-NET-WebAPI-REST

http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

Раньше я сталкивался с той же проблемой. Логин не очень хорошо подходит для дизайна, основанного на ресурсах.

Я обычно обрабатываю это, имея ресурс входа в систему и передавая имя пользователя и пароль в строке параметра, в основном выполняя

ПОЛУЧИТЬ на http://myservice/login?u= {username} & p = {password}

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

Альтернативой GET для ресурса входа в систему является выполнение POST, пуристы REST, вероятно, меня сейчас не полюбят :) и передача кредитов в теле. Ответ будет таким же.