我需要到OAuth2在iOS和Android原生应用程序集成。 我一直在研究上的OAuth2和移动应用,发现这个文件- 谷歌的API -使用OAuth 2.0安装应用程序
上述文档基本上详细描述了如何消耗在移动应用中的Goolge的OAuth 2.0端点。
这里是文件说什么 -
- 当注册应用程序,您指定的应用程序是一个已安装的应用。 这导致了REDIRECT_URI参数不同的值。
- 登记期间所获得的CLIENT_ID和client_secret被嵌入在应用程序的源代码。 在此背景下,client_secret显然不是当作一个秘密。
- 该授权码可以返回到您的应用程序在浏览器的标题栏或到
http://localhost
查询字符串端口。
比方说,用户安装在他们的智能手机2个应用程序。
应用1 - 合法的应用程序消耗谷歌OAuth2.0的端点
应用2 - 恶意应用
真的是我不能肯定是集成/消费OAuth2.0的端点的本地移动应用程序中的上述技术是否是不安全的还是我失去了一些东西。 这里是我的问题 -
- 该REDIRECT_URI可以是
http://localhost
URL,并且可以包含任何端口号。 的端口号是不是初始API配置的一部分,因此它可以是任何有效的端口号。 另外,CLIENT_ID(不应该是秘密反正)和client_secret不是真正的秘密,因为它们被嵌入在移动应用程序源代码。
使用上述条件,是不是以下的可能性 -
- 用户启动应用2
- 应用2用户对谷歌的OAuth2.0端点然而重定向请求中,应用2包括CLIENT_ID对APP和包括其上应用2监听本地端口号。
- 当用户被重定向和验证到谷歌OAuth2.0的端点,谷歌将显示给用户的是“应用1(合法应用程序)的要求访问代表用户的谷歌API的/数据”,这似乎是由于网络钓鱼攻击用户可以单击是认为它是应用1所要求的访问。
- 那么谷歌的OAuth2.0会发出一个授权码应用2,然后应用2可以包括应用1的CLIENT_ID下一个请求和client_secret并获得和的access_token和refresh_token继续从谷歌获取用户数据。
- 所述REDIRECT_URI还可以是 - 瓮:IETF:WG:OAuth的:2.0:OOB这意味着 -
此值信号的授权码,应在浏览器的标题栏返回的谷歌授权服务器。 当客户端不能没有显著客户端配置的HTTP端口上侦听,这非常有用。 Windows应用程序具有这种特征。
当使用这个值,你的应用程序能感觉到页面加载和HTML页面的标题包含的授权码。 然后由你的应用程序,如果你想确保用户不会看到包含授权码的页面,关闭浏览器窗口。 这样做的机制,从平台而异。
以上意味着,授权码在浏览器窗口的标题返回。
我的问题是 - 应用2还可感觉到页面加载和捕捉到的授权码,然后用它(应用前)与CLIENT_ID一起和client_secret获得和的access_token refresh_token。 是浏览器实例全球任何应用程序可以监视它和上面的攻击情形是有效的或者说是浏览器实例莫名其妙专用,以便只有应用1可以感知/监控的变化?
我的理解是正确的还是我失去了一些东西? 我缺少的是减轻上述威胁的任何缓解? 或者上述风险的有效接受的,但考虑到我们是一个移动OS平台上?
什么是移动应用程序中使用的OAuth2.0的安全呢? - 显示在浏览器页面的授权码,并让用户在应用程序中手动输入? 而在这种情况下,是浏览器实例私有,这样其他应用程序无法监控它和用户类型之前获取授权代码本身的抱进合法apication?
任何帮助表示赞赏
感谢致敬,