OAuth на iPhone: используя Safari или UIWebView?

Question

Когда я реализую OAuth в iPhone, у меня есть дилемма, чтобы выбрать Safari или UIWebView, чтобы открыть страницы Twitter для аутентификации пользователей? Я пишу некоторые преимущества и недостатки обоих случаев: Использование UIWebWeb. Недостатком является то, что пользователи должны вводить свои учетные данные в нашем приложении. Это может быть рискованное фишинг. Преимущество такого подхода не будет прекращено в нашем приложении.

Использование Safari для аутентификации пользователя (этот подход автоматически вызывает обратные вызовы в нашем приложении). Addvantage: менее рискованно. Недостатки: придется бросить наше приложение

Хорошая ссылка ссылку об этом: http://fireeagle.yahoo.net/developer/documentation/oauth_best_practice

Какой подход вы предпочитаете? Любой ответ оценен. Благодарю.

Answer 1

Для лучшего пользовательского опыта с Destop и мобильными приложениями, мы должны использовать XAUTH: http://docs.google.com/View?id=ddkz8b2q_76d95356mz

Answer 2

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

Answer 3

Я уже реализовал это как набор классов (с открытым исходным кодом). Не стесняйтесь смотреть: http://github.com/bengottlieb/Twitter-OAuth-iPhone

Answer 4

Парень, который пару лет назад сделал приложение Pownce для iPhone, публично обсуждал с ним это.

Его блог, похоже, больше не работает, но в основном он реализовал его как «правильный», насколько это касается OAuth. Вместо того, чтобы вводить учетные данные внутри приложения, Safari был запущен, и они были введены там, а затем пользовательский URL-адрес iPhone использовался в качестве обратного вызова для повторного запуска приложения Pownce. Довольно аккуратный, а?

Спустя некоторое время разработчик следил за комментарием, что многие пользователи загружали приложение, но фактически не использовали его. Его вывод? Это виновата его блестящая схема OAuth. Пользователи были смущены запуском Safari и выведены из приложения.

Будьте честными, хотя? Я считаю, что виноват тот факт, что приложение предназначалось для Pownce, службы, которую никто не использовал.

У меня есть приложение в магазине приложений прямо сейчас, в котором используется API Foursquare, который поддерживает как Basic HTTP auth, так и OAuth. Я решил «поступить правильно» и использовать OAuth. Пользователь вводит свои учетные данные прямо внутри моего приложения. Я сохраняю их имя пользователя и пароль в любом месте? Неа. Но мог ли я быть? Конечно.

Может показаться, что я спорю для обеих сторон здесь, но на самом деле все это сводится к тому, что маловероятно, что ваши пользователи будут знать или даже заботиться о том, что такое OAuth. Вероятно, так же маловероятно, что они даже подумают дважды о том, чтобы добавить свои учетные данные в ваше приложение. OAuth отлично (чертовски много лучше, чем OpenID), но не был разработан с учетом iPhone. Он создан для работы внутри веб-браузера. Я думаю, что документы Foursquare API docs лучше всего говорят о своей схеме OAuth для мобильных устройств/Desktop (отличной от того, что они хотят сделать для веб-приложения) - «Мы предоставляем этот механизм в предположении, что если пользователь установил ваше приложение на их аппаратном обеспечении они доверяют ему достаточно, чтобы передать свою информацию об аутентификации в foursquare."

Answer 5

По состоянию 31 мая 2017 и далее, там не осталась Мы MUST использования Safari варианта. , так как google теперь не поддерживает OAuth через UIWebView. Обратитесь к this link для получения более подробной информации.