iPhone上的OAuth：使用Safari还是UIWebView？

Question

当我在iPhone中实施OAuth时，选择Safari或UIWebView打开Twitter页面以进行用户身份验证时，我处于两难境地？ 我写了两种情况的优点和缺点： 使用UIWebWeb。缺点是用户必须在我们的应用程序中输入他们的凭据。这可能是冒险的网络钓鱼。优点是这种方法不会退出我们的应用程序。

使用Safari进行身份验证（此方法自动回调我们的应用程序）Addvantage：风险较小。缺点：必须退出我们的应用程序

关于此的一个很好的参考链接：http://fireeagle.yahoo.net/developer/documentation/oauth_best_practice

您更喜欢哪种方法？ 任何回应都表示赞赏。感谢。

Answer 1

绝大多数用户不会理解或关心这种区别。做任何让他们的生活变得更轻松的事情，或者 - 在其他条件相同的情只要你值得信赖（你不网络钓鱼或偷看他们的凭据，对吗？），你将提供良好的体验而不是将其搞砸。在这种情况下，我会使用UIWebView。

Answer 2

几年前做过Pownce iPhone应用程序的人有点公开辩论过这个问题。

他的博客似乎不再起作用，但就OAuth而言，基本上他以“正确”的方式实施了它。而不是在应用程序内部输入凭证，Safari已启动并在那里输入，然后使用自定义iPhone URL作为重新启动Pownce应用程序的回调。非常整洁，嗯？

一段时间后，开发人员随后发表评论说很多人都在下载应用程序但实际上没有使用它。他的结论？他的出色OAuth计划应该归咎于他。用户对Safari启动和从应用程序中删除感到困惑。

说实话但是？我认为该应用程序适用于Pownce这一无人使用的服务这一事实应该归咎于此。

我现在在应用程序商店中有一个使用Foursquare API的应用程序，它支持Basic HTTP auth和OAuth。我决定“做正确的事”并使用OAuth。用户直接在我的应用程序内输入他们的凭据。我可以在任何地方以纯文本格式保存用户名和密码吗？不。但我可以吗？当然。

这可能听起来像我在这里争论双方，但真正归结为你的用户不太可能知道甚至关心OAuth是什么。他们甚至可能会三思而后行，将他们的凭据放入您的应用程序中。 OAuth非常棒（比OpenID好多了）但是并没有考虑到iPhone的设计。它是为在Web浏览器内部工作而构建的。我认为Foursquare API文档在谈论他们的移动/桌面客户端OAuth方案（与他们希望您为Web应用程序做的不同）时说得最好 - “我们假设如果用户已安装您的应用程序，则提供此机制在他们的硬件上，他们相信它足以将他们的身份验证信息传递给foursquare。“

Answer 3

我已经将它实现为一组插件（开源）。请随意查看：http://github.com/bengottlieb/Twitter-OAuth-iPhone

Answer 4

为了获得桌面和移动应用程序的最佳用户体验，我们应该使用xAuth： http://docs.google.com/View?id=ddkz8b2q_76d95356mz

Answer 5

从 2017年5月31日开始，没有选项。我们必须使用Safari，因为谷歌现在不通过UIWebView支持OAuth。有关详细信息，请参阅this链接。