OAuth 2.0 中的客户端密码
要使用 google drive api，我必须使用 OAuth2.0 进行身份验证。我有几个关于这个的问题。
客户端 ID 和客户端密码用于识别我的应用程序是什么。但如果它是客户端应用程序，它们必须是硬编码的。因此，每个人都可以反编译我的应用程序并从源代码中提取它们。这是否意味着一个糟糕的应用程序可以通过使用好应用程序的客户端 id 和密码来伪装成一个好应用程序？所以用户会显示一个屏幕，要求授予一个好应用程序的权限，即使它实际上是由一个坏应用程序要求的？如果是，我该怎么办？或者实际上我不应该担心这个？在移动应用程序中，我们可以将 webview 嵌入到我们的应用程序中。并且很容易在 webview 中提取密码字段，因为请求权限的应用程序实际上是一个“浏览器”。那么，移动应用程序中的 OAuth 没有客户端应用程序无法访问服务提供商的用户凭证的好处吗？
我和这里的问题 1 有同样的问题，最近自己做了一些研究，我的结论是可以不保守“客户秘密”的秘密。在 OAuth2 规范中，不保密客户端机密的客户端类型称为“公共客户端”。以下事实阻止了恶意用户获取授权码，然后访问令牌的可能性。
1.客户端需要直接从用户获取授权码，而不是从服务获取
即使用户表明他/她信任客户端的服务，客户端也无法仅通过显示客户端 ID 和客户端密码从服务中获取授权码。相反，客户端必须直接从用户那里获取授权码。 （这通常通过 URL 重定向来完成，我稍后会谈到。）因此，对于恶意客户端，仅知道用户信任的客户端 id/secret 是不够的。它必须以某种方式涉及或欺骗用户来给它授权码，这应该比只知道客户端 ID/秘密更难。
2. 重定向 URL 使用客户端 id/secret 注册
假设恶意客户端以某种方式设法让用户参与进来，并让她/他点击服务页面上的“授权此应用程序”按钮。这将触发从服务到带有授权代码的用户浏览器的 URL 重定向响应。然后授权码将从用户的浏览器发送到重定向 URL，并且客户端应该正在监听重定向 URL 以接收授权码。 （重定向 URL 也可以是 localhost，我认为这是“公共客户端”接收授权码的典型方式。）由于此重定向 URL 使用客户端 id/secret 在服务中注册，因此恶意客户端不会有一种方法可以控制授权码的提供位置。这意味着具有您的客户端 id/secret 的恶意客户端在获取用户的授权码方面还有另一个障碍。
我开始对您的问题发表评论，但后来发现有太多要说的，所以这是我对答案中该主题的看法。
是的，这确实有可能，并且有一些基于此的漏洞利用。建议不要在您的应用程序中保密应用程序，甚至在规范中有一部分分布式应用程序不应使用此令牌。现在您可能会问，但 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 规范并说“现在我很安全”，而是使用常识，通常不使用他们不信任的应用程序。
回答第二个问题：出于安全原因，Google API 要求不能在应用程序本身内完成身份验证/登录（例如不允许 web 视图），并且需要使用浏览器在应用程序外部完成，以获得更好的安全性，这将在下面进一步解释：{1 }
