问题：我相信我理解PKCE对隐式流的改进，但使用PKCE的用户机器与应用程序接收&在后端处理授权代码？
背景：我们的团队一直在寻求在不同产品的组合中添加/实现单一登录。其中包括一个带有登录表单/cookie的旧网站，一个目前使用对称JWT的SPA/PWA，以及一个也使用JWT的桌面应用程序插件。我们的Auth0定价过高，因此希望通过MS&或谷歌登录。
作为试验，我们得到了"；授权码授权流"；使用常规web应用程序。即，用户被重定向到他们完成的MS/Google登录，并被重定向回授权码，我们的服务器收到授权码，然后我们将其与客户机密一起交换，以获得他们的ID令牌。在这一点上，我们可以验证他们是谁&我们可以像往常一样用cookie让他们登录。
查看SPA组件的开发人员使用了一个库，该库默认情况下使用PKCE流，因此客户端自己最终获得了ID令牌，然后可以将其发送给我们进行JWT验证。验证JWT的过程似乎并不太复杂，但它确实让我产生了疑问，为什么不想从他们那里收到授权码？我看了一些示例实现，当使用非PKCE授权代码流时，一些库只是信任它从Microsoft收到的ID令牌，因为端点是应用程序事先已知的/最终用户无法配置的。
不再建议使用隐式流，当您希望通过浏览器对用户进行身份验证时，应使用 授权代码流PKCE是授权代码流的重要安全升级，用于保护身份提供程序返回的授权代码。 不使用隐式流和使用PKCE是当今的最佳实践。 https://www.oauth.com/oauth2-servers/pkce/ 为了获得最佳安全性，不再建议在浏览器内处理身份验证流和令牌。相反，更好的方法是使用这些视频中提到的BFF流：