您所描述的是标准的SPA方式-它可能被恶意代码滥用，但由于授权代码只能使用一次，并且验证器不会存储很长时间，因此有一定的保护作用。
一个相关的XSS攻击是在一个隐藏的iframe上运行一个完整的OAuth授权重定向+代码交换--没有针对该攻击的保护措施，无论是否涉及后端或客户端机密。
如果您想严格要求安全性，那么正在出现的趋势更多的是后端对前端的方法，其中后端是运行在https://api.mywebdomain.com上的“代理API

• OAuth授权的结果是API发出的相同站点cookie，以防止上述iframe攻击
• SPA然后可以使用auth cookie来获得访问令牌，或者通过代理API来获得双跳API请求。

最近有一个关于SPA安全here的很好的视频，更深入地讨论了这些威胁。浏览器是一个很难实现安全的地方，重定向伴随着风险。
但是，仍然建议将Web和API问题分开-例如，上述代理API不应妨碍公司通过内容交付网络部署其SPA。

登录舞蹈

在我看来，首选的方法总结如下，为完全控制和没有问题的最近浏览器的变化：

• SPA调用诸如https://api.mywebdomain.com/login/start之类的URL，该URL为. www.example.com写入仅限HTTP的加密cookiemywebdomain.com包含状态和code_verifier，并且SPA还返回授权请求URL
• 然后SPA自己进行重定向，并在需要时预先将页面位置/状态保存到会话存储中
• SPA接收到带有代码和状态的响应URL后，将其POST到https://api.mywebdomain.com/login/end等URL中，之后SPA可以恢复其页面位置和状态，因此可用性较好。
• API通过验证状态cookie中的状态来完成登录，然后使用状态cookie中的code_verifier。所有这些操作的结果是编写一个无法在iframe上滥用的auth cookie（包含刷新令牌）。

我同意加里的方法，但有一点改变：带有代码和状态的响应url不需要被SPA截获并转换为对BFF的另一个POST调用如果在包含状态和代码验证器的流的开始在浏览器上设置安全cookie，响应url可以直接到达BFF，BFF然后将具有可用于执行代码交换的所有参数（状态和代码作为url参数，来自cookie的code_verifier）