从Chrome自定义标签重定向到Android应用时,"导航被屏蔽"

Question

我正在"现代化"我们的登录小部件以使用Chrome自定义标签,因为Google将在几个月内开始使用网页浏览来阻止OAuth请求.

登录小部件与我们的身份服务一起使用,该服务支持经典的"用户名和密码"登录和社交登录,通过Google/Facebook /授权代码流中的OAuth2"客户端"播放...因此Google的授权代码将传送给此身份服务,它又为我们的登录窗口小部件提供访问令牌.

访问令牌通过客户端重定向传递回移动应用程序:

window.location.replace('com.acmeusercontent.tenants.abc:\/setTokenData?accessToken='+access_token+'#');

一切都适合经典登录:用户填写用户名和密码并提交,返回访问令牌,重定向到自定义URI方案会触发我的RedirectReceiverActivity的intent-filter.

但是,对于社交登录,重定向没有任何反应,除了Android监视器中的这一行:

I/chromium: [INFO:CONSOLE(0)] "Navigation is blocked: com.acmeusercontent.tenants.abc:/setTokenData..."

需要明确的是:对于经典登录和社交登录,客户端重定向完全相同,但在经典登录后,允许在社交登录后被阻止!并且,如果我向窗口小部件添加一个按钮,该按钮在社交登录后执行完全相同的重定向,则只要用户单击它就可以再次允许.

这让我感到困惑: - 为什么重定向有时会被允许,有时会被阻止？- 除了要求用户在社交登录序列完成后单击按钮之外,还有什么方法可以解决这个问题吗？

我尝试了我能想到的一切:使用"intent:"语法,使用服务器端重定向模拟从代码中单击按钮,......但没有任何作用.此外,我使用Google身份验证示例研究了AppAuth库,据我所知,我做的完全相同.

Answer 1

我是AppAuth的主要维护者.

Chrome端的触发重定向到应用程序的策略,无论是通过自定义方案还是https App Link,都必须由用户触发此操作,而不是Javascript.我相信这里的目的是防止用户在没有以点击链接的形式明确"同意"的情况下打开应用程序时出现意外情况.

对于在授权请求中立即重定向回重定向URI的身份提供程序,这是有问题的:打开自定义选项卡和重定向之间不会发生任何操作.

我维护了一个演示,演示了如何捕获OAuth重定向并在用户单击此处后将其转发到应用程序:

https://github.com/iainmcgin/AppAuth-Demo

另一个可能的选择是捕获后端上的重定向参数,然后使用302重定向到您的自定义方案来响应浏览器.由于这维护了用户操作的单个重定向"链",因此应该允许这样做.不幸的是,这要复杂得多,因为您现在可能不得不使用OAuth2状态参数作为在应用程序重定向发生后从服务器检索参数的键.AppAuth无法直接帮助,因为它希望从浏览器直接向其提供授权响应.