PKCE：重定向端点如何知道code_verifier？

Question

我对PKCE（RFC 7636）有疑问。使用授权代码授权的OAuth客户端有两个组件：（1）资源所有者启动授权请求的设备部分;（2）服务器上可以接受和发送HTTPS消息的重定向端点。 / p>

OAuth的PKCE扩展让客户端执行此操作：

1. 生成一个名为code_verifier的加密随机字符串。
2. 创建code_verifier的SHA-256摘要并对其进行Base64编码。 与授权请求一起发送。
3. 当客户端获取授权代码并将其发送到令牌时 访问令牌的端点，包括原始的code_verifier值。

第2步发生在资源所有者的设备上。一旦资源所有者批准了该请求，他/她的浏览器就被重定向到客户端的重定向端点。步骤3发生在重定向端点。

所以问题是，重定向端点如何知道code_verifier值？它是在资源所有者的设备上生成的。

Answer 1

  

所以问题是，重定向端点如何知道   code_verifier值？它是在资源所有者的设备上生成的。

因为重定向端点有效地路由到调用授权端点的同一设备上的端点。

它可能被注册为环回重定向，应用程序声明的重定向或自定义URL方案，但设备会将重定向路由到相应的应用程序，或者应用程序将侦听相应的端口以进行环回。

  

使用授权代码授权的OAuth客户端有两个   组件：（1）资源所有者设备上的部分   发起授权请求和（2）重定向端点   可以接受和发送HTTPS消息的服务器。

机密客户端在可以接受和发送HTTPS消息的服务器上具有重定向端点。

公共客户端没有 - 使用PKCE的本地客户端是still public clients。

Answer 2

为了构建所提供的信息，PKCE旨在确保重定向URI通过授权代码拦截攻击路由回请求应用程序，而不是恶意应用程序。在这种情况下，合法应用程序将知道验证程序，但恶意应用程序将不知道验证程序。

PKCE合法应用流程

合法的应用程序流如下所示，授权令牌请求被重定向回SystemBrowser，然后返回到原始NativeApp。

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

授权码拦截攻击

可以将恶意应用程序引入操作系统。使用或不使用PKCE，本机应用程序可以接收授权代码，但它不会知道验证者，因此无法完成令牌交换。

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