根据https://auth0.com/docs/get-started/authentication-and-authorization-flow/call-your-api-using-the-authorization-code-flow-with-pkce：
PKCE规范定义了两种方法，S256和plain，前者在本示例中使用，并且是Auth0唯一支持的方法，因为后者是不鼓励的。
为什么他们设计它，使plain甚至是一个有效的值使用？
如果您使用plain，那么如果授权码被盗，code_verifier也可能被盗，因为它与code_challenge的值相同。
我看不出这能增加什么安全感。
2条答案
按热度按时间uplii1fm1#
这与其说是为了向后兼容，不如说是因为两者都是在同一时间标准化的，在同一规范中，尽管当时可能存在一些早期采用者部署的“普通”。
它主要是为了适应那些无法生成SHA 256哈希的受限环境，因为平台上根本不存在这种能力，因为/或者加载/运行成本太高。记住，常规的OAuth/OIDC客户端可以在不执行任何加密操作的情况下运行，强制对所有形式的PKCE使用加密是很麻烦的。
不带SHA的普通PKCE被设计用于提高移动的上的安全性（因此是公共的）客户端，其中恶意的共安装应用可以尝试拦截授权响应以窃取授权代码。当不使用PKCE时，它将能够仅使用公共已知的静态参数在令牌端点处交换该代码。当应用（即使是普通的）PCKE，恶意应用程序也必须窃取/拦截传出的授权请求，以访问为每个授权请求动态生成的
code_challenge/code_verifier。拦截认证响应和请求需要不同的技术。对于攻击者来说，前者被认为相对容易，只需注册一个处理程序，用于重定向URI的URL方案，替换合法应用程序的URL方案。拦截传出请求可能更复杂。无论如何，结合两种不同的攻击技术可能比一种更困难，这就是为什么普通PKCE被认为对某些情况仍然有用。
ecfsfe2w2#
说明书上说：
如果客户端能够使用“S256”，则必须使用“S256”，如
“S256”是服务器上的强制实施（MTI）。客户端
仅当它们不能支持某些应用程序的“S256”时，才允许使用“plain”
并通过带外配置了解
服务器支持“plain”。
普通转换是为了与现有的
部署以及无法使用S256的受限环境
转型
所以我想它只是出于向后兼容的原因而出现在规范中。
来源：https://www.rfc-editor.org/rfc/rfc7636