要使用google drive api,我必须使用OAuth2.0进行身份验证 . 我对此有一些疑问 .
-
客户端ID和客户端密钥用于标识我的应用程序是什么 . 但是如果它是客户端应用程序,它们必须是硬编码的 . 因此,每个人都可以反编译我的应用程序并从源代码中提取它们 . Does it mean that a bad app can pretend to be a good app by using the good app's client id and secret? 因此,即使实际上是由坏应用程序询问,用户也会显示一个要求授予好应用程序权限的屏幕?如果是,我该怎么办?或者实际上我不应该担心这个?
-
在移动应用程序中,我们可以将webview嵌入到我们的应用程序中 . 并且很容易在webview中提取密码字段,因为要求许可的应用程序实际上是"browser" . So, OAuth in mobile application does not have the benefit that client application has not access to the user credential of service provider?
3 回答
我开始在你的问题上写评论,但后来发现有太多话要说,所以这里是我对答案中主题的看法 .
例如,Facebook的Facebook库中存在一些错误,它们将令牌泄露给日志,你可以在这里找到更多关于它的信息http://attack-secure.com/all-your-facebook-access-tokens-are-belong-to-us和这里https://www.youtube.com/watch?v=twyL7Uxe6sk . 总而言之,你对第三方库的使用要格外小心(实际上是常识,但如果令人担忧的是劫持令牌,请谨慎添加额外的额外内容) .
我和这里的问题1有同样的问题,最近我自己做了一些研究,我的结论是,不要把“客户秘密”保密 . 不保守客户机密密码的客户端类型在OAuth2规范中称为“公共客户端” . 以下事实阻止了某人恶意获取授权代码然后访问令牌的可能性 .
1.客户需要直接从用户获取授权代码,而不是从服务获取授权代码
即使用户指示他/她信任客户端的服务,客户端也只能通过显示客户端ID和客户端密钥来从服务获取授权代码 . 相反,客户端必须直接从用户获取授权代码 . (这通常通过URL重定向来完成,我将在稍后讨论 . )因此,对于恶意客户端,仅知道用户信任的客户端ID /秘密是不够的 . 它必须以某种方式涉及或欺骗用户给它授权代码,这应该比知道客户端ID /秘密更难 .
2.重定向URL已使用客户端ID / secret注册
让我们假设恶意客户端以某种方式设法让用户参与并让她/他点击服务页面上的“授权此应用程序”按钮 . 这将触发从服务到用户浏览器的URL重定向响应及其授权代码 . 然后授权代码将从用户的浏览器发送到重定向URL,并且客户端应该在重定向URL处侦听以接收授权代码 . (重定向URL也可以是localhost,我认为这是“公共客户端”接收授权代码的典型方式 . )由于此重定向URL在具有客户端ID / secret的服务中注册,因此恶意客户端不会有办法控制授权代码的位置 . 这意味着恶意客户端与您的客户端ID / secret有另一个障碍获取用户的授权代码 .
回答第二个问题:出于安全原因,Google API要求无法在App内部进行身份验证/登录(例如不允许使用Web视图),并且需要使用浏览器在应用程序外部进行更好的安全性,这将在下面进一步说明:https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html