19

我正在“现代化”我们的登录小部件以使用 Chrome 自定义选项卡，因为Google 将在几个月后开始使用 Webviews 阻止 OAuth 请求。

登录小部件与我们的身份服务配合使用，该服务支持经典的“用户名和密码”登录和社交登录，通过在 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 库，据我所知，我正在做同样的事情。

4

1 回答 1

25

我是 AppAuth 的主要维护者。

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

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

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

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

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

于 2017-01-26T20:47:46.737 回答