android - 使用代理服务器的手机上的OAuth是否太麻烦了？

Question

最近几天，我开始安装并运行OAuth实现。不是在Android上，而是在我的Web服务器上，它将充当受OAuth保护的服务的代理。我将要实现我的Android客户端，而我的头脑仍在围绕安全性和实现问题进行讨论。

当客户端只是一个网络浏览器时，OAuth太困惑了。您需要执行以下一系列步骤:

(客户端Web浏览器)向我的代理服务器

发出请求

(代理服务器)从OAuth提供者请求未经授权的 token (例如-网络服务API)

(代理服务器)要求OAuth提供者让用户对 token 进行授权。将网络浏览器重定向到OAuth提供者的“授权” URI

(OAuth提供程序)，用户完成授权后，将浏览器重定向到您的回调URI

(代理服务器::回调URI)将访问 token 交换授权 token ，然后将其存储以供将来调用

对OAuth提供者进行API调用，并将响应文档返回给客户端Web浏览器

现在就足够了。但是，当将与移动应用程序相同的机制用作客户端时，它会涉及更多。问题当然是您必须做一些杂技，才能在进行OAuth跳舞时将浏览器 session 注入(inject)到您的移动应用程序的代码流中。这意味着您必须进一步使OAuth舞蹈复杂化，如下所示(在此示例中，我使用的是Android应用来具体说明):

(移动网络应用程序:: native 代码)使用Java/HTTP

从代理服务器发出请求

(代理服务器)从OAuth提供者请求未经授权的 token (例如-网络服务API)

(代理服务器)将响应文档返回到移动Web应用程序，该响应文档包含用于OAuth提供者进行用户授权的重定向URI，最好对其进行混淆以隐藏使用者 key 和其他详细信息，以阻止“空中”监听。

(移动Web应用程序)使用授权URL和已安装的 Intent 过滤器启动Web浏览器 Activity 。但是，存储并使用特殊的“phony” URI替换并替换代理服务器的指定回调URI，以便通过 Intent 过滤器轻松识别URI(请参阅以下步骤)

(OAuth提供程序)，用户完成授权后，将浏览器重定向到您的“phony”回调URI。

(移动Web应用程序) Intent 过滤器检测“假”回调URI，并使用该信号重新获得控制权。重建代理服务器的回调URI并使用Java/HTTP执行请求。

(代理服务器::回调URI)将访问 token 交换授权 token ，然后像

之前一样存储它以供将来调用

对OAuth提供程序进行API调用，并将响应文档返回到移动Web应用程序

如您所见，这非常可怕。如果有更简单的方法可以做到这一点，那么我很想听听。据我所知，只有两个其他选择，每个都有自己的重大问题。

1)不用代理服务器，直接从移动Web应用程序执行所有操作。这里最大的安全漏洞是您必须“烘烤” OAuth使用者 key 并将其 secret 应用到您的应用程序中。如果攻击者对您的代码进行反编译并查找这些字符串，这对有反向工程经验的人来说是相当容易的操作，那么他们可能会对您的应用程序和用户造成严重破坏。

2)切换到XAuth，其中用户为您提供其登录名和密码，并且您“同意”不存储它们，而是直接将它们交换为XAuth服务器的访问 token 。第一个问题是获得用户的信任以提供该信息，这是OAuth旨在解决的问题，当然，那些不遵守 promise 放弃登录详细信息的人又该怎么办？更糟糕的是，XAuth服务器必须支持XAuth并提供HTTPS(SSL)连接，而且我已经看到大量不支持两者的Web API。 SSL连接当然是必需的，因为如果没有它，您将在发出XAuth请求时以纯文本的形式发送用户的登录名和密码。

http://blog.zyber17.com/post/1283741364/why-xauth-is-a-really-dumb-idea

仅供引用，尽管它不使用代理服务器，但以下示例说明了我上文所述的用于将浏览器 session 注入(inject)到您的移动应用OAuth交互中并拦截回调URI的技术:

http://blog.doityourselfandroid.com/2010/11/10/oauth-flow-in-android-app/

因此，从任何角度看，这似乎都很丑陋，而且我什至没有为用户创建和管理自己的用户ID所带来的烦恼，因此您可以正确查找存储在代理Web服务器上的用户访问 token (包括另一个PIN或访问代码供用户管理的困惑情况)。

有趣的旁注:在研究Android Web浏览器 session 安全性时，我很高兴发现您不被允许访问当前网页HTML。如果您可以访问它，那么敌对的Android编码器可能会轻易嗅出用户的登录名和密码，从而完全破坏OAuth的目的和 Intent 。我很沮丧地发现可能存在一种通过CacheManager对象获取HTML的方法。奇怪的是，现在该对象已被弃用，并计划根据Android文档进行删除，因此希望这意味着Google发现了(潜在的)安全漏洞，并正在采取措施在即将发布的版本中将其删除:

http://developer.android.com/reference/android/webkit/CacheManager.html

最后，我想听听那些在创建OAuth应用程序时遇到这些同样问题的人的想法。

-罗施勒

Answer 1

Janrain已发布了一个库，该库提供了一些UI粘合和代理后端登录系统。它支持许多流行的OAuth身份提供商(例如Google/FB)。在登录流程结束时，您将从设备获得HTTPS POST，为您提供可交换的 token ，用于交换用户标识符和其他信息，以及向设备返回访问 token 的 channel 。

http://www.janrain.com/products/engage/mobile

https://github.com/janrain/engage.android

披露:我在Janrain的这个图书馆工作。