这个问题是关于尝试了解在Android等移动平台上实施oauth所涉及的安全风险。这里的假设是我们有一个Android应用程序，它在代码中嵌入了消费者密钥/秘密。
假设一个消费者的秘密受到了损害，并且黑客已经掌握了它，那么这会带来什么后果呢？
妥协的消费者秘密假设
我是否正确地指出，受损的消费者秘密对用户的安全性或用户正在与之交互的OAuth启用的提供商中存储的任何数据没有影响。数据本身不受损害，黑客无法检索。
黑客需要获得一个有效的用户访问令牌，这很难获得。
黑客可以通过妥协的消费者秘密做些什么？
我还说明了以下内容：
最终用户影响
在假设
可能会发生以下情况：
OAuth使用者（我的应用程序）影响：
我的应用程序（包含消费者秘密）需要更新，否则我的所有客户都无法授权我的应用程序再代表他们的请求（因为我的消费者秘密将不再有效）。
委派所有OAuth流量
虽然可以通过中间网络服务器委派大量OAuth交互（进行OAuth舞蹈并将访问令牌发送给用户），但也需要代理所有服务交互，因为需要使用消费者密钥/秘密用于签署每个请求。这是将消费者密钥/秘密保留在移动应用程序之外，并存储在中间网络服务器上更安全的地方的唯一方法吗？
替代
这种代理有替代方案吗？是否可以将消费者秘密存储在中间网络服务器上，并且具有某种机制，即Android应用程序（在市场上发布并正确签名）可以向中间网络服务器发出安全请求以获取消费者秘密并存储它应用程序内部？可以实现一种机制，中间网络服务器“知道”这是一个请求获取消费者秘密的官方Android应用程序，并且中间网络服务器只会将消费者秘密分发给该特定的Android应用程序吗？
答案 0 :(得分：52)
摘要：我会冒险并将密码保存在客户端应用中。
代理服务器替代：
您可以合理地缓解我在下面列出的问题以及进行代理工作的唯一方法是整个九码 - 将处理第三方Web服务上的资源的所有业务逻辑移动到您的代理服务器，并使客户端应用程序哑终端具有丰富的UI。这样，恶意应用程序能够代表其执行代理的唯一操作将只是您的业务逻辑合法需要的操作。
但是现在你已经处理了一系列其他必须处理可靠性和可扩展性的问题。
仔细考虑为什么简单代理不起作用：
有些人在面对的时候 问题，想想“我知道，我会添加我的 自己的代理服务器“现在他们有两个 问题。 （向Jamie道歉 Zawinski撰写）
您的假设基本上是正确的。一直到你开始考虑你自己的服务器，它是保守秘密和代理客户端应用程序的调用，或者它试图确定应用程序是否合法并给它秘密。在这两种方法中，您仍然必须解决“这个请求来自我写的一段代码”的问题吗？
让我再说一遍 - 没有办法在线上区分出特定的软件正在运行。如果消息中的数据看起来正确，则无法证明这是发送该消息的另一个应用。
在一天结束时，如果我正在编写一个恶意应用程序，我不在乎我是否真的知道真正的秘密，只要我能让那些知道它代表我的人工作。因此，如果您认为恶意应用可以将您的应用模拟到第三方OAuth服务器，为什么您确定它无法将您的应用模拟到您的代理？
但等等，还有更多。您的代理服务所在的域名是您的客户和OAuth提供商的身份（OAuth提供商向最终用户显示）。如果恶意应用程序可以使您的服务器做坏事，不仅您的密钥被撤销，而且您的公共Web身份也不再受信任。
我将从显而易见的开始 - 没有办法在线上区分特定的软件正在运行。如果消息中的数据看起来正确，则没有任何东西可以证明它是发送该消息的另一个应用程序。
因此，任何依赖于应用程序端存储的秘密的算法都可能被欺骗。 OAuth的优势在于它永远不会向用户提供应用程序的凭据，而是为应用程序提供自己的临时凭据，用户可以在必要时撤消该凭据。
当然，这里的弱点是，一个足够好的应用程序可以让用户信任它，而不是在它完成其邪恶的行为之前撤销凭据。
然而，缓解这种情况的一种方法是谷歌使用三足OAuth的方法，而不是标准的两条腿。在三足OAuth中，没有预先分配的秘密，但在每次认证时，都会发出新的访问令牌密钥以及每个访问令牌。虽然最终这也有同样的缺点，因为糟糕的应用程序可以从其进程中读取好的应用程序的令牌秘密，但它确实导致用户每次需要新的访问令牌时都必须批准应用程序访问。
当然，这也意味着它对用户来说更加不方便和烦人。