从 Chrome 自定义选项卡重定向到 Android 应用程序时“导航被阻止”

Question

我正在“现代化”我们的登录小部件，以使用 Chrome 自定义标签作为 Google will start blocking OAuth requests using Webviews in a few months。

登录小部件与我们的身份服务配合使用，该服务支持经典的“用户名和密码”登录和社交登录，方法是在 Google/Facebook/...的授权代码流中播放 OAuth2“客户端”... 因此，来自 Google 的授权代码被传递到此身份服务，该身份服务反过来为我们的登录小部件提供访问令牌。

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

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

对于经典登录来说一切都很好：用户填写用户名和密码并提交，返回访问令牌，重定向到自定义 URI 方案会触发我的 RedirectReceiverActivity 的意图过滤器。

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

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

要明确一点：对于经典登录和社交登录，客户端重定向完全相同，但是在经典登录后允许，而在社交登录后被阻止！ 而且，如果我向小部件添加一个按钮，该按钮在社交登录后执行完全相同的重定向，则再次允许它 - 只要用户单击它。

这让我很困惑： - 为什么重定向有时被允许有时被阻止？ - 除了要求用户在社交登录序列完成后点击按钮之外，有没有任何方法来解决这个问题？

我尝试了所有我能想到的方法：使用“intent:”语法，从代码中模拟单击按钮，使用服务器端重定向，......但没有任何效果。 此外，我通过 Google 身份验证示例研究了AppAuth libraries，据我所知，我正在做同样的事情。

Answer 1

我是 AppAuth 的主要维护者。

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

这对于在授权请求上立即重定向回重定向 URI 的身份提供者来说是有问题的：在打开自定义选项卡和重定向之间不会发生任何操作。

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

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

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