OAuth 2.0中的客户端密钥

Question

要使用google drive api,我必须使用OAuth2.0进行身份验证.我对此有一些疑问.

1. 客户端ID和客户端密钥用于标识我的应用程序是什么.但是如果它是客户端应用程序,它们必须是硬编码的.因此,每个人都可以反编译我的应用程序并从源代码中提取它们.这是否意味着一个糟糕的应用程序可以通过使用好的应用程序的客户端ID和秘密伪装成一个好的应用程序？所以用户会显示一个屏幕,要求授予一个好应用程序的权限,即使它实际上是由一个糟糕的应用程序询问？如果是,我该怎么办？或者实际上我不应该担心这个？

2. 在移动应用程序中,我们可以将webview嵌入到我们的应用程序中.并且很容易在webview中提取密码字段,因为请求许可的应用程序实际上是"浏览器".那么,移动应用程序中的OAuth没有客户端应用程序无法访问服务提供商的用户凭据的好处？

Answer 1

我开始在你的问题上写评论,但后来发现有太多话要说,所以这里是我对答案中主题的看法.

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

   例如,Facebook的Facebook库中存在一些漏洞,它们将令牌泄露给日志,你可以在这里找到更多关于它的信息 http://attack-secure.com/all-your-facebook-access-tokens-are-belong到我们 这里和https://www.youtube.com/watch?v=twyL7Uxe6sk.总而言之,你对第三方库的使用要格外小心(实际上是常识,但如果令人担忧的是劫持令牌,请谨慎添加额外的额外内容).

2. 很长一段时间以来,我一直在争论第2点.我甚至在我的应用程序中做了一些变通方法以修改同意页面(例如更改缩放和设计以适应应用程序)但是没有什么能阻止我使用用户名和密码从Web视图中的字段读取值.因此,我完全赞同你的第二点,并发现它是OAuth规范中的一个重大"错误".在规范中指出"应用程序无法访问用户凭据"只是一个梦想,并给用户带来虚假的安全感......此外,我猜人们通常会怀疑应用程序要求他们提供Facebook,Twitter,Dropbox或其他凭据.我怀疑很多普通人阅读OAuth规范并说"现在我很安全",而是使用常识,一般不使用他们不信任的应用程序.

Answer 2

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

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

即使用户指示他/她信任客户端的服务,客户端也只能通过显示客户端ID和客户端密钥来从服务获取授权代码.相反,客户端必须直接从用户获取授权代码.(这通常通过URL重定向来完成,我将在稍后讨论.)因此,对于恶意客户端,仅知道用户信任的客户端ID /秘密是不够的.它必须以某种方式涉及或欺骗用户给它授权代码,这应该比知道客户端ID /秘密更难.

2.重定向URL使用客户端ID/secret注册

让我们假设恶意客户端以某种方式设法让用户参与并让她/他点击服务页面上的"授权此应用程序"按钮.这将触发从服务到用户浏览器的URL重定向响应及其授权代码.然后授权代码将从用户的浏览器发送到重定向URL,并且客户端应该在重定向URL处侦听以接收授权代码.(重定向URL也可以是localhost,我认为这是"公共客户端"接收授权代码的典型方式.)由于此重定向URL在具有客户端ID/secret的服务中注册,因此恶意客户端不会有办法控制授权代码的位置.这意味着具有您的客户端ID/secret的恶意客户端有另一个障碍来获取用户的授权代码.