OAuth 2.0 中的客户端密码答案

【问题标题】：client secret in OAuth 2.0OAuth 2.0 中的客户端密码
【发布时间】：2013-11-06 01:53:25
【问题描述】：

要使用 google drive api，我必须使用 OAuth2.0 进行身份验证。我有几个关于这个的问题。

客户端 ID 和客户端密码用于识别我的应用程序是什么。但如果它是客户端应用程序，它们必须是硬编码的。因此，每个人都可以反编译我的应用程序并从源代码中提取它们。 这是否意味着一个坏应用可以通过使用好应用的客户端 ID 和密码来伪装成一个好应用？所以用户会显示一个屏幕，要求授予一个好应用的权限，即使它实际上是由一个糟糕的应用程序询问的？如果是，我该怎么办？或者实际上我不应该担心这个？
在移动应用程序中，我们可以将 webview 嵌入到我们的应用程序中。并且很容易在 webview 中提取密码字段，因为请求权限的应用程序实际上是一个“浏览器”。 那么，移动应用中的 OAuth 没有客户端应用无法访问服务提供者的用户凭证的好处吗？

【问题讨论】：

另外我猜当应用程序要求他们提供他们的 Facebook、Twitter、Dropbox 或其他凭据时，人们通常会怀疑。我怀疑许多普通人阅读 OAuth 规范并说“现在我安全了”，而是使用常识，通常不使用他们不信任的应用程序。
真的是一个很棒的问题肯定应该有更多的分数
您可以从您的服务器下载 ClientId 和密码，并在首次成功登录时将其保存在钥匙串中
@Sharvan 我可能错了，但我认为钥匙串在 root 手机上很容易受到攻击，因此您的客户秘密可能会被公开。

标签： security oauth google-api oauth-2.0

【解决方案1】：

我开始为您的问题写评论，但后来发现有太多话要说，所以这是我对答案中的主题的看法。

是的，这确实有可能，并且有一些基于此的漏洞利用。建议不要在您的应用程序中保密应用程序，甚至在规范中有一部分分布式应用程序不应使用此令牌。现在您可能会问，但 XYZ 需要它才能工作。在这种情况下，他们没有正确实施规范，您应该 A 不要使用该服务（不太可能）或 B 尝试使用一些混淆方法来保护令牌，以使其更难找到或使用您的服务器作为代理。

例如，Android 的 Facebook 库中存在一些将令牌泄漏到日志的错误，您可以在此处找到有关它的更多信息 http://attack-secure.com/all-your-facebook-access-tokens-are-belong-to-us 在这里https://www.youtube.com/watch?v=twyL7Uxe6sk。总而言之，在使用第三方库时要格外小心（实际上是常识，但如果令牌劫持是您的大问题，请额外谨慎）。
我已经对第 2 点大发雷霆很久了。我什至在我的应用程序中做了一些变通方法以修改同意页面（例如更改缩放和设计以适应应用程序），但没有什么能阻止我使用用户名和密码从 Web 视图内的字段中读取值。因此，我完全同意您的第二点，并在 OAuth 规范中发现它是一个很大的“错误”。在规范中指出“应用程序无法访问用户凭据”只是一个梦想，并给用户带来了错误的安全感……而且我猜当应用程序要求他们提供他们的 Facebook、Twitter、Dropbox 或其他凭据时，人们通常会怀疑。我怀疑很多普通人会阅读 OAuth 规范并说“现在我安全了”，而是使用常识，通常不会使用他们不信任的应用程序。

【讨论】：

您的客户端 ID 和客户端密码不会因为您将它们发布在 SSL 隧道中而安全。是的，它们对中间人的攻击更安全。如果用户代理您的 HTTPs 调用，他们可以接受错误的证书并查看您发布的所有内容。顺便说一句，这是在移动设备上窃取某人客户机密的最简单方法。
感谢您的评论，但无法以任何方式将其与我的答案联系起来...您能否详细说明您为何评论我的答案，因为我明确表示不应使用客户端密码分布式应用程序，另一点是即使使用 OAuth，也有一些解决方法可以在应用程序中获取用户凭据，因此用户应该信任应用程序提供商而不是 OAuth。
另外，我不明白您所说的“如果用户代理您的 HTTPs 调用”是什么意思，是的，用户可以访问他们使用 HTTPs 发送的数据，并且他们可以随意代理调用。据我了解，您建议将其作为拆卸 apk 以获取秘密的一个很好的替代方案，但是您不应该首先发送应用程序秘密。
所以对于第 1 点）坏应用需要访问同一系统并从 same 设备检索访问/刷新令牌？
不清楚在这种情况下您认为什么是“同一系统”。应用程序创建一个 web 视图，其中显示确认页面，并且可以访问该视图中的所有数据（包括托管访问令牌的 cookie 或 url 参数）。在某些情况下，跨应用访问也是可能的，例如，如果一个应用可以访问其他应用日志，它可以在那里找到令牌，如 fb lib bug 所述。

【解决方案2】：

我和这里的问题 1 有同样的问题，最近自己做了一些研究，我的结论是，不保守“客户秘密”是可以的。在 OAuth2 规范中，不保密客户端机密的客户端类型称为“公共客户端”。以下事实阻止了恶意用户获取授权码，然后访问令牌的可能性。

1。客户端需要直接从用户获取授权码，而不是从服务获取

即使用户表明他/她信任客户端的服务，客户端也无法仅通过显示客户端 ID 和客户端密码从服务中获取授权码。相反，客户端必须直接从用户那里获取授权码。（这通常是通过 URL 重定向来完成的，我稍后会谈到。）因此，对于恶意客户端，仅知道用户信任的客户端 id/secret 是不够的。它必须以某种方式涉及或欺骗用户才能给它授权码，这应该比只知道客户 ID/秘密更难。

2。重定向 URL 已使用客户端 id/secret 注册

假设恶意客户端以某种方式设法让用户参与其中并让她/他点击服务页面上的“授权此应用”按钮。这将触发从服务到带有授权代码的用户浏览器的 URL 重定向响应。然后授权码将从用户的浏览器发送到重定向 URL，客户端应该监听重定向 URL 以接收授权码。（重定向 URL 也可以是 localhost，我认为这是“公共客户端”接收授权码的典型方式。）由于此重定向 URL 使用客户端 ID/秘密在服务中注册，因此恶意客户端无法控制将授权代码提供给何处。这意味着具有您的客户端 id/secret 的恶意客户端在获取用户的授权码方面还有另一个障碍。

【讨论】：

这很有希望，你有这方面的参考吗？知道会让人放心。
我在云端硬盘文档中看到，在已安装的应用程序中，客户端密码并不是真正的密码，但他们没有解释为什么可以将其存储在那里。你的解释帮了大忙！

【解决方案3】：

回答第二个问题：出于安全原因，Google API 要求不能在应用程序本身内完成身份验证/登录（例如不允许 web 视图），并且需要使用浏览器在应用程序外部完成以提高安全性，这将在下面进一步说明： https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html

【讨论】：

至少在我问过 3 年后它已经“修复”了 :)