OAuth 2.0中的客户端机密

要使用Google Drive API，我必须使用OAuth2.0进行身份验证。我对此有一些疑问。

1. 客户端ID和客户端机密用于识别我的应用程序。但是，如果是客户端应用程序，则必须对其进行硬编码。因此，每个人都可以反编译我的应用程序并从源代码中提取它们。这是否意味着坏应用程序可以使用好应用程序的客户端ID和机密假装成好应用程序？因此，即使实际上是由不良应用程序提出的请求，用户也会显示一个屏幕，要求授予对良好应用程序的许可？如果是，该怎么办？还是实际上我不应该为此担心？

2. 在移动应用程序中，我们可以将Webview嵌入到我们的应用程序中。而且很容易提取Web视图中的密码字段，因为要求许可的应用程序实际上是“浏览器”。那么，移动应用程序中的OAuth是否没有客户端应用程序无法访问服务提供商的用户凭证的好处？

我开始对您的问题发表评论，但随后发现要说的话太多了，所以这里是我对答案主题的看法。

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

   例如，Android的Facebook库中存在一些漏洞，该漏洞会将令牌泄漏到Logs，您可以在此处找到有关此漏洞的更多信息 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规范并说“现在我很安全”，而是使用常识并且通常不使用他们不信任的应用程序。

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

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

即使用户指示他/她信任客户端的服务，客户端也不能仅通过显示客户端ID和客户端密码来从该服务获得授权码。相反，客户端必须直接从用户那里获取授权代码。（这通常是通过URL重定向完成的，这将在后面讨论。）因此，对于恶意客户端而言，仅知道用户信任的客户端ID /秘密是不够的。它必须以某种方式涉及或欺骗用户为其提供授权代码，这比仅知道客户端ID /秘密要困难。

2.重定向URL已用客户端ID /秘密注册

假设恶意客户端以某种方式设法使用户参与进来，并使他/他单击服务页面上的“授权此应用”按钮。这将触发带有服务授权码的URL重定向响应，从服务到用户的浏览器。然后，授权码将从用户的浏览器发送到重定向URL，并且客户端应该在重定向URL处侦听以接收授权码。（重定向URL也可以是localhost，我认为这是“公共客户端”接收授权代码的一种典型方式。）由于此重定向URL是在服务中使用客户端ID /秘密注册的，因此恶意客户端不会有一种方法可以控制将授权码分配到何处。

回答第二个问题：出于安全原因，Google API要求身份验证/登录不能在App本身内完成（例如，不允许执行Webviews），并且需要使用浏览器在App外部进行身份验证才能获得更好的安全性，下面将对此进行进一步说明： https： //developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html