问"code_verifier“在OAuth 2.0中的意义是什么？

EN

code_verifier确实是敏感的:客户端在对令牌端点的调用中证明它首先是发起授权请求的机制。

此值应保密，另见下文。

泄漏它将允许攻击者在对授权服务器的令牌端点的调用中模拟(公共)客户端，从而获得用于实际客户端的令牌。

请注意，即使在code_verifier上不使用任何(散列)转换，但在授权请求中以plain的形式发送它，也会使能够拦截对重定向URI的回调的攻击者感到困难，因为他还必须拦截传出请求。

但是通常情况下，code_verifier应该使用SHA256散列到code_challenge中，因此即使在拦截请求时，攻击者也无法推断code_verifier。

来自RFC第1节

OAuth 2.0 RFC6749公共客户端容易受到授权代码拦截攻击。 在此攻击中，攻击者截获在传输层安全(TLS)不受保护的通信路径中从授权端点返回的授权代码，例如客户端操作系统中的应用程序间通信。 一旦攻击者获得了对授权代码的访问权限，就可以使用它来获取访问令牌。 ..。 为了减轻这种攻击，此扩展使用了动态创建的名为“代码验证器”的加密随机密钥。为每个授权请求创建唯一的代码验证器，并将其转换后的值“代码挑战”发送到授权服务器以获得授权代码。然后将所获得的授权代码用“代码验证器”发送到令牌端点，并且服务器将其与先前接收的请求代码进行比较，以使其能够执行客户端拥有“代码验证器”的证明。这起缓解作用，因为攻击者不知道这个一次性密钥，因为它是通过TLS发送的，不能被拦截。

这里的关键词组是：“客户端拥有‘代码验证器’的证据，因为攻击者不知道这个一次性密钥，因为它是通过TLS发送的，不能被拦截。”

TL;DR：

代码challenge+verifier对是证明请求身份验证令牌的客户端与请求授权代码的客户端相同(或受其信任)的关键。如果代码验证器被泄露，那么RFC中提到的攻击(本质上是利用交叉交谈模拟合法应用程序的恶意应用程序)没有得到缓解，因此PKCE (防止这种攻击)的目的就被挫败了。