要使用google drive api，我必须使用OAuth2.0进行身份验证。我对此有一些疑问。
客户端ID和客户端密码用于标识我的应用是什么。但是如果它是客户端应用程序，它们必须是硬编码的。因此，每个人都可以反编译我的应用程序并从源代码中提取它们。 这是否意味着一个糟糕的应用程序可以通过使用优秀的应用程序的客户端ID和秘密伪装成一个好的应用程序？因此用户将显示一个屏幕，要求授予一个好的应用程序的权限，即使它实际上是一个糟糕的应用程序问？如果是，我该怎么办？或者实际上我不应该担心这个？
在移动应用程序中，我们可以将webview嵌入到我们的应用程序中。并且很容易在webview中提取密码字段，因为请求许可的应用程序实际上是“浏览器”。 因此，移动应用程序中的OAuth没有客户端应用程序无法访问服务提供商的用户凭据的好处吗？
答案 0 :(得分：14)
我开始在你的问题上写评论，但后来发现有太多话要说，所以这里是我对答案中主题的看法。
是的，确实存在这种可能性，并且基于此存在一些漏洞。建议不要在应用程序中保密应用程序，规范中甚至有一部分分布式应用程序不应使用此令牌。现在您可能会问，但是XYZ需要它才能工作。在这种情况下，他们没有正确实现规范，你应该A不使用该服务（不太可能）或B尝试使用一些混淆方法来保护令牌，使其更难找到或使用您的服务器作为代理。
例如，Facebook的Facebook库中存在一些漏洞，它们将令牌泄露给Logs，你可以在这里找到更多关于它的信息 http://attack-secure.com/all-your-facebook-access-tokens-are-belong-to-us 在这里https://www.youtube.com/watch?v=twyL7Uxe6sk。 总而言之，你对第三方库的使用要格外小心（实际上是常识，但如果令人担忧的是令牌劫持，请谨慎添加额外的额外内容）。
我一直在争论第2点。我甚至在我的应用程序中做了一些变通方法以修改同意页面（例如更改缩放和设计以适应应用程序）但是没有什么能阻止我使用用户名和密码从Web视图中的字段读取值。因此，我完全同意你的第二点，并发现它是一个很大的错误＆＃34;在OAuth规范中。点是＆＃34;应用程序无法访问用户凭据＆＃34;在规范中只是一个梦想并给用户带来虚假的安全感......我猜人们通常会怀疑当app询问他们的Facebook，Twitter，Dropbox或其他凭据时。我怀疑很多普通人都会阅读OAuth规范并说“＃34;现在我很安全＆＃34;但是使用常识并且通常不使用他们不信任的应用程序。
答案 1 :(得分：10)
我在这里遇到了与问题1相同的问题，并且最近自己做了一些研究，我的结论是可以不将“客户秘密”保密。 不保守客户机密密码的客户端类型在OAuth2规范中称为“公共客户端”。 以下事实阻止了某人恶意获取授权代码然后访问令牌的可能性。
即使用户指示他/她信任客户端的服务，客户端也只能通过显示客户端ID和客户端密钥来从服务获取授权代码。 相反，客户端必须直接从用户获取授权代码。 （这通常通过URL重定向完成，我将在稍后讨论。） 因此，对于恶意客户端，仅知道用户信任的客户端ID /秘密是不够的。它必须以某种方式涉及或欺骗用户给它授权代码， 这应该比知道客户端ID /秘密更难。
假设恶意客户端以某种方式设法让用户参与并让她/他点击服务页面上的“授权此应用程序”按钮。 这将触发从服务到用户浏览器的URL重定向响应及其授权代码。 然后授权代码将从用户的浏览器发送到重定向URL，并且客户端应该在重定向URL处侦听以接收授权代码。 （重定向URL也可以是localhost，我认为这是“公共客户端”接收授权代码的典型方式。） 由于此重定向URL在具有客户端ID / secret的服务中注册，因此恶意客户端无法控制授予代码的位置。 这意味着具有您的客户端ID / secret的恶意客户端有另一个障碍来获取用户的授权代码。
答案 2 :(得分：0)
回答第二个问题：出于安全原因，Google API要求无法在App内部进行身份验证/登录（例如不允许使用Web视图），并且需要使用浏览器在应用程序外部进行更好的安全性，这将在下面进一步说明： https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html