OpenID连接: PKCE后通道授权代码

Question

问题：我相信我理解PKCE对隐式流的改进，但是在使用PKCE的用户机器与应用程序接收和处理后端授权代码的授权代码流之间，安全性有什么根本的区别呢？

背景：我们的团队一直在寻求在不同的产品组合中添加/实现单点登录。其中包括一个具有登录表单/cookie的旧网站，一个目前使用对称JWT的SPA/PWA，以及一个使用JWT的桌面应用程序插件。我们的Auth0价格已经不高了，所以我们希望通过微软和/或谷歌的登录来利用OpenID连接。

作为一个尝试，我们已经得到了“授权代码授予流程”与常规网络应用程序。也就是说，用户被重定向到他们完成的MS/Google登录，用授权代码重定向回来，我们的服务器接收授权代码，我们与客户端秘密交换这些信息以获得他们的ID令牌。在这一点上，我们可以验证他们是谁&我们可以正常地用cookie登录。

查看SPA组件的开发人员使用了默认使用PKCE流的库，因此客户机本身以ID令牌结束，然后可以将其发送给我们进行JWT验证。验证JWT的过程似乎不太复杂，但它确实让我怀疑为什么不想从他们那里接收授权代码呢？我看了一些示例实现，当使用非PKCE授权代码流时，一些库只是信任它从Microsoft收到的ID令牌，因为应用程序事先知道端点/最终用户无法配置。

Answer 1

不再建议使用隐式流，当您想通过浏览器对用户进行身份验证时，应该使用授权代码流。

PKCE是授权码流的重要安全升级，它保护由身份提供程序返回的授权代码。

不使用隐式流和使用PKCE是当今的最佳实践。

https://www.oauth.com/oauth2-servers/pkce/

为了获得最好的安全性，不再需要重新处理浏览器中的身份验证流和令牌。相反，更好的方法是使用这些视频中提到的BFF流：

• 警报‘OAuth 2.0’；// XSS对SPAs中OAuth 2 0的影响
• 使用BFF模式保护SPA和Blazor应用程序