OAuth versus HTTP-based auth

Это вообще разные вещи :) OAuth - это не просто протокол аутентификации, это протокол делегирования авторизации.

Я читал маны, смотрел диаграммки OAuth. Какой смысл в такой сложности?

Если гуглить лень, то фишка делегирования в том, что никакое из приложений (а их овер 9000) не принимает твой логин и пароль, а отправляет тебя на oauth твиттера, который в итоге дает токен, с которым приложение может авторизоваться в твиттере от твоего имени. Если юзать http-auth пароли бы перли в огромном количестве. Ну и из приятностей - если ты уже залогинен на твиттере, то тебе нужно просто нажать кнопочку «поддтверждаю»

ME хочет логиниться только в google, а не все сайты ходить по oauth, а то регаться задалбливает. Эх мечты-мечты.

хочет логиниться только в google, а то регаться задалбливает

А всякий openID разве не для этого?

А всякий openID разве не для этого?

По логике своей (но не по факту) OAuth и есть расширение OpenID.

а отправляет тебя на oauth твиттера

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

А всякий openID разве не для этого?

OpenID для этого. OAuth для другого: пользователь U зарегистрирован на ресурсе P. Он может позволить другому ресурсу Q делать запросы к P от имени U или к данным U и при этом контролировать этот доступ.

А всякий openID разве не для этого?

Да, для этого. Но OAuth это умеет в том числе, и OpenID накрывается медным тазом. Так сложилось.

Если это приложение для смартфона, то там все запросы браузера я могу перехватить.

Как? На сколько я знаю нельзя. Полученный код приложение получает через браузерный редирект на my-app://...?token=..., как-то так.

Угу, но приложение Q может от имени пользователя запросить профиль самого пользователя на ресурсе P и создать учетку, привязав ее к id пользователя на ресурсе P. Ускоренная регистрация просто частный случай делегирования авторизации.

А если браузер открывается внутри приложения как компонент? Например, Everplaces. Да любое приложение можно так сделать, и сервис не заметит - открыт браузер изнутри приложения или это обычный.

OpenID это штука которая говорит да, это ты владелец этого идентификатора.
OAuth это штука которая позволяет передать третьей стороне часть прав твоего акаунта.

По логике они вобще перпендикулярны.

Я понял - OAuth имеет смысл для браузерных приложений, чтобы один сайт не узнал мои credentials для другого сайта.

Но для небраузерных приложений oauth смысла не имеет .

Я понял

Но для небраузерных приложений oauth смысла не имеет .

Короче, ничего ты не понял.

Ну так поясни.

Тебе уже написали, зачем он нужен. Причем тут браузер?

Цель OAuth какая? Обеспечить безопасную авторизацию через третью сторону?

нет *facepalm*

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

И да, что я все равно не пойму как там пароль можно перехватить. Ну то есть я верю, что в принципе можно, но как технически?

Но для небраузерных приложений oauth смысла не имеет .

Если реализовывать правильно, чтобы человека из приложения выкидывало в браузер, а браузер ловил редирект на приложение, то вполне имеет.

. Ну то есть я верю, что в принципе можно, но как технически?

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

Вот так - да, это будет работать, и полностью безопасно.

Цель OAuth какая? Обеспечить безопасную авторизацию через третью сторону?

Насколько я понял, цель OAuth - это дать третьей стороне возможность что-то делать в Facebook аккаунте пользователя от имени этого пользователя, но

1. делегируется только часть полномочий (т.е. тебе могут разрешить показывать аватар пользователя, но не его фотоальбомы, или писать на стене, но не отправлять инвайты от его имени),

2. авторизация при этом, разумеется тоже нужна, но такая, чтобы логин и пароль пользователь вводил на сайте фейсбука, на не на третьем сайте (поэтому, она там примерно такая, как в OpenID). Соответственно, если ты уже авторизован в фейсбуке, ты просто просто подтверждаешь, что разрешаешь третьему сайту убедиться, что ты и есть ты.

Таким образом, OpenID - это только авторизация (после приделали передачу 8 фиксированных полей для упрощения регистрации на сайтах с использованием OpenID, чтобы не заполнять заново данные, которые уже есть у OpenID провайдера). А OAuth - это делегирование части полномочий на действия над аккаунтом от имени пользователя (но для этих действий нужна и авторизация тоже, и, так получилось, что она по духу и по сути очень похода на тот способ, который используется в OpenID, basicAuth тут не подходит, потому что сайт сможет почти все что угодно сделать с аккаунтом). Разработчики OAuth долго думали, как можно расширить OpenID для получения дополнительной функциональности, но решили сделать свой протокол.

Еще одно различие между ними: если твой сайт просто авторизует по OpenID, то любой пользователь может дать тебе любой адрес и ты сможешь воспользоваться соответствующим адресу OpenID провайдером, для проверки авторизации (даже если ты никогда не знал об этом провайдере). В OAuth, тебе нужно будет сначала получить eToken для приложения (или как он там называется) у Facebook, чтобы использовать их OAuth, токен у гугла, токен у mail.ru и так далее. Нет токена OAuth провайдера - не сможешь авторизовывать пользователя этого провайдера. Таким образом OAuth реализует vendor lock пользователей. Поэтому по нормальному у провайдера должен всегда быть OpenID только для авторизаций и Oauth, если нужно предоставить больший функционал.

авторизация

Люди, перестаньте путать идентификацию, аутентификацию и авторизацию!

Люди, перестаньте путать идентификацию, аутентификацию и авторизацию!

Я в курсе, что OpenID это аутентификация, OAuth - авторизация, но тогда было бы больше букв и слов, но менее понятно.

За напоминание - спасибо.

Теперь все ясно. Боагодарю!