Yohoho！我正在构建一个利用OAuth从提供者API提取用户数据的应用程序，我想知道我选择的流是否符合RFC。
目前，用户登录到授权服务器，授权服务器会向我的前端客户端发送身份验证代码。然后，前端将身份验证代码传递给我的后端，后端将其交换为身份验证令牌，然后调用提供程序来提取数据。
在这份最佳实践文件中，它指出：
注意：尽管到目前为止PKCE被推荐为一种保护机制本机应用程序，此建议适用于所有类型的OAuth客户端，包括web应用程序。
据我所知，PKCE旨在确保令牌被授予请求身份验证代码的同一实体，以防止攻击者使用被盗的身份验证代码执行不必要的请求。
现在，我明白了为什么即使后端保持客户端机密不公开，这一点也很重要，因为攻击者可以使用截获的身份验证代码向后端发出接收令牌的请求。然而，在我的流程中，由于我没有创建身份验证方案，而是试图授权有预谋的请求，因此令牌留在后端。
那么为什么这里推荐PKCE呢？在我看来，被盗的身份验证代码所能做的最多的事情就是从后端发起API请求，而不会向攻击者返回令牌或数据。假设PKCE实现是可行的，那么它究竟是如何工作的呢？请求身份验证代码的前端和用它交换令牌的后端并不完全相同，那么它会像将code_verifier传递到后端进行调用一样简单吗？
如有澄清，不胜感激。
PKCE确保启动登录的一方也在完成登录，下面我将总结两种关于单页应用程序(SPA(的主要变体。
公众客户
考虑一个运行仅用Javascript实现的代码流的单页应用程序。这将在OpenID Connect重定向期间将代码验证器存储在会话存储中。登录后返回应用程序时，会将其与授权代码和状态一起发送到授权服务器。
这将向浏览器返回令牌。如果存在跨站点脚本漏洞，则该流可能会被滥用。特别是，恶意代码可能会启动一个隐藏的iframe，并使用prompt=none以静默方式获取令牌。
机密客户
因此，当前单页应用程序的最佳实践是使用前端后端(BFF(，并且从不向浏览器返回令牌。在该模型中，BFF更自然地像传统的OpenID Connect网站一样操作，其中state和code_verifier都存储在持续登录过程的login cookie中。
如果存在跨站点脚本漏洞，则session riding可能通过恶意代码将授权代码发送给BFF并完成登录。然而，这只会导致编写浏览器无法访问的安全cookie。同样，隐藏的iframe破解也只会重写cookie。
code_verifier也可以存储在会话存储器中，并从浏览器发送到BFF，但恶意代码很容易获取它并将其发送到服务器。这并不能真正改变风险，关键是不应将任何令牌返回到浏览器。在浏览器中使用次要安全值是可以的，只要你能证明它们的合理性，例如安全审查人员。一般来说，如果安全值在安全cookie中，并且对Javascript不太可见，则更容易解释。
更多信息
最佳实践通常因客户用例而异，在Curity，我们为客户(和普通读者(提供资源来解释安全的设计模式。这些是基于安全标准的，我们将它们转化为客户用例。你可以发现我们最近的SPA安全白皮书很有用。