我正在将我们的登录小部件“现代化”,使用Chrome自定义标签作为Google将在几个月内开始阻止使用Webview的OAuth请求。
登录小部件与我们的身份验证服务配合工作,该服务支持经典的“用户名和密码”登录和社交登录,通过在授权代码流中扮演Google/Facebook/...的OAuth2“客户端”来实现。因此,来自Google的授权代码被传递到此身份验证服务,该服务反过来向我们的登录小部件提供访问令牌。
访问令牌通过客户端重定向传递回移动应用程序:
window.location.replace('com.acmeusercontent.tenants.abc:\/setTokenData?accessToken='+access_token+'#');
针对经典登录,用户填写用户名和密码并提交后,会返回访问令牌,并触发自定义URI方案的重定向来触发RedirectReceiverActivity的意图过滤器。
然而,对于社交登录,在重定向时除了Android Monitor中的这一行之外,什么都不会发生:
I/chromium: [INFO:CONSOLE(0)] "Navigation is blocked: com.acmeusercontent.tenants.abc:/setTokenData..."
仅为明确起见:对于经典登录和社交登录,客户端重定向完全相同,但在经典登录后允许,而在社交登录后被阻止! 如果我在小部件中添加一个按钮,在社交登录后执行完全相同的重定向,它会再次允许-只要用户点击即可。
这让我感到困惑: -为什么有时允许重定向,有时又被阻止? -除了要求用户在社交登录序列完成后单击按钮之外,是否有任何方法可以绕过此问题?
我尝试了我能想到的一切:使用“intent:”语法,从代码模拟按钮点击,使用服务器端重定向等,但都没有成功。 此外,我研究了AppAuth libraries与Google身份验证示例,并且据我所知,我正在做完全相同的事情。