HTTP basic auth, digest auth и Oauth?

Какой из базовых auth, digest auth и Oauth следует использовать для моего веб-приложения, чтобы позволить пользователям получать доступ к ресурсам через вызовы Restful API.

Не Oauth лучшее решение, заменяющее базовый и дайджест auth?

Ответы

Ответ 1

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

Basic может работать со многими клиентами браузера данных, такими как Sesame, а также работать с Excel 2010, а также с любым старым браузером. единственная проблема - это пароли, перемещающиеся в ящике, которые могут быть смягчены путем размещения вашего приложения через https.

Не знаю много о дайджесте, к сожалению.

Я лично пытаюсь протестировать реализацию каждого из них: http basic и oauth.

Ответ 2

Глянцевание многих деталей здесь, но:

http basic: отправить имя пользователя и пароль в поле "Очистить" в заголовке Authorize

http digest: отправить имя пользователя и пароль, где пароль был хэширован сервером, предоставленным nonce

Обе версии oauth изначально предназначены для предоставления третьим сторонам доступа к ресурсам, которые им не принадлежат (например, я разрешаю мобильному фотоприложению отправлять почту в facebook от моего имени), не предоставляя третьему лицу мои учетные данные. Оба этих протокола работают в основном следующим образом:

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

oauth1.0a: более безопасный, чем oath2, но более сложный для реализации также требует, чтобы все запросы подписывались.

oauth2: полагается на ssl для обеспечения безопасности и не требует подписи запроса. В то время как ведущий автор отказался от проекта, потому что он считает, что он не соответствует ни одной из его первоначальных целей дизайна (безопасность, интероперабельность), он широко используется Facebook и Google.

Вот несколько статей, которые я нашел полезными здесь:

Недостаточно mojo еще для ссылки на rfcs, но это окончательные источники, если они немного неудобоваримы.

Ответ 3

У Фила Осергона есть приличная книга (Build APIs You Won ' t Hate) со всей главой, посвященной аутентификации. Он охватывает:

  • Основные
  • Дайджест
  • OAuth 1.0a
  • OAuth 2

Я бы очень рекомендовал его прочитать, если вы планируете внедрять такие механизмы в свой RESTful API.

Обновление Почему downvote?