Security OAuth 2.0中的客户端机密

要使用GoogleDriveAPI，我必须使用OAuth2.0进行身份验证。我有几个问题要问

客户端id和客户端机密用于标识我的应用程序是什么。但如果是客户端应用程序，则必须对其进行硬编码。所以，每个人都可以反编译我的应用程序并从源代码中提取它们这是否意味着一个坏应用可以通过使用好应用的客户端id和密码来伪装成一个好应用？所以用户会显示一个屏幕，要求授予一个好应用权限，即使它实际上是由一个坏应用请求的？如果是，我该怎么办？或者实际上我不应该担心这个

在移动应用程序中，我们可以将webview嵌入到我们的应用程序中。在webview中提取密码字段也很容易，因为请求权限的应用程序实际上是一个“浏览器”因此，移动应用程序中的OAuth没有客户端应用程序无法访问服务提供商的用户凭据的好处？

---

我开始就你的问题写评论，但后来发现有太多的话要说，所以下面是我对这个问题的看法

是的，这是一个真正的可能性，有一些基于此的漏洞。建议不要在应用程序中保守应用程序的秘密，规范中甚至有一部分规定分布式应用程序不应使用此令牌。现在您可能会问，但是XYZ需要它才能工作。在这种情况下，他们没有正确实现规范，您不应该使用该服务（不太可能），或者尝试使用一些模糊方法来保护令牌，以使查找或使用服务器作为代理变得更加困难

例如，Android的Facebook library中存在一些漏洞，它将令牌泄漏到日志中，您可以在这里找到更多信息 在这里。 总而言之，在使用第三方库时要格外小心（事实上是常识，但如果令牌劫持是你的大问题，那么再多加一点小心）

---

关于第二点，我已经咆哮了很长一段时间了。我甚至在我的应用程序中做了一些变通方法，以修改同意页面（例如更改缩放和设计以适应应用程序），但没有任何东西阻止我使用用户名和密码从web视图内的字段中读取值。因此，我完全同意你的第二点，并发现它是OAuth规范中的一个大“缺陷”。规范中的“应用程序无法访问用户凭据”只是一个梦想，给用户带来了虚假的安全感……而且我猜当应用程序要求他们提供Facebook、Twitter、Dropbox或其他凭据时，人们通常会产生怀疑。我怀疑许多普通人阅读OAuth规范并说“现在我安全了”，但他们使用常识，通常不使用他们不信任的应用程序

---

我的问题与第一个问题相同，最近我自己也做了一些研究，我的结论是，不保守“客户秘密”是可以的。 在OAuth2规范中，不保持客户机机密性的客户机类型称为“公共客户机”。 以下事实可以防止恶意用户获取授权代码，然后访问令牌

1.客户端需要直接从用户而不是从服务获取授权代码 即使用户表示他/她信任客户机的服务，客户机也无法仅通过显示客户机id和客户机机密从服务中获取授权代码。 相反，客户端必须直接从用户处获取授权代码。（这通常是通过URL重定向完成的，我将在后面讨论。） 因此，对于恶意客户端，仅知道用户信任的客户端id/机密是不够的。它必须以某种方式涉及或欺骗用户，才能给它授权码， 这应该比只知道客户id/机密更难

2.重定向URL已使用客户端id/secret注册 让我们假设恶意客户端设法让用户参与进来，并让用户单击服务页面上的“授权此应用”按钮。 这将触发从服务到用户浏览器的URL重定向响应，其中包含授权代码。 然后，授权代码将从用户的浏览器发送到重定向URL，客户端应该在重定向URL上侦听以接收授权代码。 （重定向URL也可以是localhost，我认为这是“公共客户端”接收授权代码的典型方式。） 由于此重定向URL是使用客户端id/secret在服务中注册的，因此恶意客户端无法控制授权代码的授予位置。

---

这意味着具有您的客户端id/secret的恶意客户端在获取用户授权码方面还有另一个障碍。

回答第二个问题：出于安全原因，谷歌API要求不能在应用程序本身内进行身份验证/登录（如不允许使用网络视图）并且需要使用浏览器在应用程序外部执行，以提高安全性，下面将进一步说明：

---

另外，我猜当应用程序要求人们提供他们的Facebook、Twitter、Dropbox或其他凭证时，人们通常会产生怀疑。我怀疑很多普通人读过OAuth规范并说“现在我安全了”但是，请使用常识，通常不要使用他们不信任的应用程序。真的，一个很好的问题肯定应该有更多的要点。您可以从服务器下载ClientId和secret，并在首次成功登录时将其保存在密钥链中it@Sharvan我可能错了，但我认为手机上的钥匙链很脆弱，因此，您的客户机密码可以公开。您的客户机id和客户机密码将不安全，因为您将它们发布在SSL隧道中。是的，他们更容易受到中间人的攻击。如果用户代理您的HTTPs呼叫，他们可以接受错误的证书并查看您发布的所有内容。顺便说一下，这是在mobi上窃取他人客户机密的最简单方法