3

我有一个关于 PKCE (RFC 7636) 的问题。使用授权代码授予的 OAuth 客户端有两个组件：(1) 资源所有者设备上发起授权请求的部分，以及 (2) 服务器上可以接受和发送 HTTPS 消息的重定向端点。

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

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

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

那么问题来了，重定向端点怎么知道code_verifier的值呢？它是在资源所有者的设备上生成的。

4

2 回答 2

2

那么问题来了，重定向端点怎么知道code_verifier的值呢？它是在资源所有者的设备上生成的。

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

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

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

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

公共客户端不使用 - 使用 PKCE 的本地客户端仍然是公共客户端。

于 2018-03-16T22:23:58.630 回答
1

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

PKCE 合法的应用程序流程

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

PKCE 合法的应用程序流

授权码拦截攻击

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

PKCE 恶意应用拦截

于 2018-06-02T16:13:16.387 回答