用OAuth实现授权后端请求的PKCE

Question

哟哟！我正在构建一个利用OAuth从提供程序API中提取用户数据的应用程序，并想知道我所选择的流程是否符合RFC。

目前，用户登录到授权服务器，该服务器向我的前端客户端发送一个auth代码。然后，前端将auth代码传递给我的后端，后者将其交换为auth令牌，然后调用提供者来提取数据。

在这个最佳做法文件中，它声明：

注意:尽管到目前为止，PKCE被推荐为一种保护本地应用程序的机制，但这个建议适用于所有类型的OAuth客户端，包括web应用程序。

据我理解，PKCE旨在确保将令牌授予请求auth代码的同一实体，以防止攻击者使用被盗的auth代码执行不必要的请求。

现在，这对我来说很有意义，即使后端不公开客户端机密，也是如此，因为攻击者可以使用截获的auth代码向后端发出请求，以接收令牌。但是，在我的流程中，由于我不是在创建身份验证方案，而是试图授权有预谋的请求，所以令牌保留在后端。

那么为什么这里推荐PKCE呢？在我看来，偷来的auth代码最多只能从后端启动API请求，而不会将令牌或数据返回给攻击者。假设PKCE实现是可行的，那么它到底是如何工作的呢？请求auth代码的前端和将其交换为令牌的后端不是完全相同的，那么它是否就像将code_verifier传递到后端进行调用一样简单呢？

如能作出一些澄清，将不胜感激。

Answer 1

PKCE确保启动登录的用户也完成了登录，并且有两个主要的变体，我将在下面总结一下单页应用程序(SPA)。

公共客户

考虑一个单独的Page，它只运行Javascript中实现的代码流。这将在OpenID连接重定向期间将代码验证器存储在会话存储中。登录后返回应用程序时，将与授权代码和状态一起发送到授权服务器。

这将向浏览器返回令牌。如果存在跨站点脚本漏洞，则流可能被滥用。特别是，恶意代码可以旋转隐藏的iframe，并使用prompt=none来静默地获取令牌。

机密客户

因此，当前单页应用程序的最佳实践是使用前端后端(BFF)，并且永远不要将令牌返回到浏览器。在这个模型中，BFF操作起来更自然，就像一个传统的OpenID连接网站，其中state和code_verifier都存储在一个login cookie中，该login cookie在登录过程中持续时间。

如果存在跨站点脚本漏洞，那么session riding就有可能通过恶意代码向BFF发送授权代码并完成登录。但是，这只会导致编写浏览器无法访问的安全cookie。类似地，隐藏的iframe黑客也只会重写cookie。

code_verifier也可以存储在会话存储中，并从浏览器发送到BFF，但是恶意代码很容易捕获它并将其发送到服务器。这并没有真正改变风险，关键是不应该将任何令牌返回到浏览器。在浏览器中使用次要安全值是可以的，只要您可以对它们进行验证，例如对于安全审查员。不过，一般来说，如果安全值在安全cookie中，对Javascript不那么可见，则更容易解释。

进一步信息

最佳实践常常因客户用例而异，因此我们为客户(和一般读者)提供了解释安全设计模式的资源。这些是基于安全标准的，我们将它们转换为客户用例。您可能会发现我们最近的SPA保安白皮书很有用。