可能的问题原因 #

Chrome 79及更高版本对非用户主动触发的自定义scheme跳转（比如myapp://）有严格的安全限制，结合你的场景，主要可能是这几个原因：

• 非用户手势触发的跳转拦截：认证流程的302重定向属于页面自动跳转，并非用户主动点击按钮/链接的操作，Chrome的安全机制会判定这类跳转存在风险，从而拦截。从Chrome 70版本开始，就加强了对这类“无用户交互”的scheme跳转的限制。
• iframe内的跳转限制：如果该机构的认证流程是在iframe中完成的，Chrome会阻止iframe内部发起的自定义scheme跳转，这是iframe的同源安全策略延伸出来的限制，避免恶意iframe随意唤起应用。
• 重定向链的触发问题：如果认证后存在多次重定向，最终才到myapp://open，Chrome会认为这是一个链式的自动跳转，而非用户直接触发的动作，同样会触发拦截机制。

可行的解决方法 #

针对这些问题，有几个经过验证的解决方案：

• 新增中间页，引导用户主动触发跳转：
  认证完成后，先重定向到一个属于你方域名的中间页面，页面上显示类似“点击打开应用”的按钮，用户点击按钮时执行window.location.href = 'myapp://open'。因为是用户主动操作，Chrome不会拦截这个跳转，这是最稳妥的方案。
• 改用Android App Links（推荐）：
  放弃自定义scheme，改用HTTPS格式的Android App Links（比如https://yourdomain.com/open），然后在你的Android应用中配置assetlinks.json文件并关联域名。这种方式符合Chrome的安全规范，浏览器会识别为合法的应用关联跳转，不会拦截，同时还能在未安装应用时引导用户到应用商店。
• 跳出iframe后再跳转（如果适用）：
  如果认证流程是在iframe中进行的，在重定向到scheme之前，先通过top.location.href跳转到顶层页面的中间页，再执行跳转逻辑，避开iframe的限制。
• 延迟自动跳转（备选方案）：
  在中间页中使用setTimeout延迟1-2秒后自动执行跳转（比如setTimeout(() => { window.location.href = 'myapp://open'; }, 1000)），部分场景下Chrome会允许这种“看似用户等待后触发”的跳转，但这个方法稳定性不如用户主动点击，仅作为备选。

内容的提问来源于stack exchange，提问作者Tymon