PKCE到底在保护什么？

Question

我想弄清楚PKCE在移动应用程序中是如何工作的，有些事情我不太明白。

因此，根据我可以收集到的信息，客户端应用程序创建了一个随机的加密安全字符串，称为代码验证器。然后将其存储起来。这样，应用程序就会生成一个代码挑战。然后将代码挑战以API请求的形式发送到服务器，以及如何生成挑战(例如S256或平原)。服务器存储此挑战以及针对所述请求的适当authorization_code。

然后，当客户端尝试将代码交换为访问令牌时，它还在请求中发送原始代码验证器。然后，服务器检索存储的问题和最初用于为该特定代码生成它的方法，并生成等效的s 256/普通散列并对它们进行比较。如果它们匹配，则返回一个访问令牌。

我不明白的是，这应该如何取代客户端应用程序中的一个秘密？当然，如果您想要欺骗这一点，您只需将client_id视为正常，并生成您自己的代码验证器和挑战，并且您处于相同的位置，就好像PKCE一开始并不是必需的。如果最初的想法是，它基本上是一个“动态秘密”，那么PKCE到底想要解决什么呢？我的假设是，只有在返回auth_code时有人碰巧在“监听”时才会出现这种情况，但是如果您再次使用SSL，这是否需要呢？它被标榜为取代了不应该在公共应用程序中存储秘密的事实，但客户端负责生成而不是服务器的事实似乎并没有起到实际的作用。

Answer 1

这个奥克塔已经在这个主题上解释了这个相当好的IMHO。

我认为这是因为PKCE是针对本地应用程序的(如Android、iOS、UWP、电子等)。其中，您离开应用程序的安全上下文，转到浏览器进行身份验证，并依赖浏览器对应用程序的安全返回。您不一定有TLS重定向回您的应用程序(在自定义方案中，您依赖操作系统将响应带回到您的应用程序)，因此如果授权代码恶意运行，接收应用程序将无法在没有动态秘密的情况下获得访问令牌。

在这里，动态秘密在公共客户机上的优点是显而易见的--对于PKCE来说，假设从浏览器拦截到应用程序的响应并不困难。

Answer 2

PKCE之所以重要是因为在移动操作系统上，操作系统允许应用程序注册处理重定向URI，这样恶意应用程序就可以注册和接收合法应用的授权代码重定向。这就是所谓的授权代码拦截攻击。

授权码拦截攻击

WSO2在这里描述了这一点：

由于可以将多个应用程序注册为特定重定向URI的处理程序，因此此流的漏洞是，恶意客户端也可以将自己注册为合法应用程序处理的同一URI方案的处理程序。如果发生这种情况，操作系统可能会将URI解析为恶意客户端。此攻击的流程如下图所示。在某些操作系统(如Android )中，在流程的第5步中，提示用户在使用“使用完全操作”活动解析重定向URI之前选择应用程序来处理重定向URI。这可能避免恶意应用程序处理它，因为用户可以识别和选择合法的应用程序。然而，一些操作系统(如iOS)没有任何这样的方案。

• 参考文献：https://docs.wso2.com/display/IS520/Mitigating+Authorization+Code+Interception+Attacks

为了更好地理解这一点，下面是来自OpenID的图表和讨论。您可以看到，移动系统浏览器有责任接收重定向URI并将其路由到正确的应用程序。

• 参考文献：http://openid.net/2015/05/26/enhancing-oauth-security-for-mobile-applications-with-pkse/

但是，由于移动OSes允许许多应用程序注册相同的重定向URI，恶意应用程序可以注册和接收合法的授权代码，如下图所示，WSO2也是这样做的：

PKCE的

攻击缓解PKCE通过在发起OAuth 2.0请求的应用程序(请求auth代码)和将auth代码交换为令牌的应用程序之间共享知识来缓解这一问题。在Auth代码拦截攻击的情况下，恶意应用程序没有验证器来完成令牌交换。